Hey guys,

I was wondering how people that make mods handle the version numbers. In short here's my defintion:

- Anything below version 0.1 is considered as Alpha version, which is similar to a test version.
- Anything below 1.0 is considered as Beta version, which means the developer thinks he got all problems fixed, but still isn't sure and so needs more testing by the community.
- As long as I add new stuff to the versions, I'll name them 0.1, 0.2, 0.3 and so on, while changing stuff or fixing problems in prior versions will be named like 0.1.1,0.2.1, 0.3.1 and so on.
- When I reach version 1.0 the mod is finished (or should be finished as initially thought) and should also be playble without bugs.
- Everything ranging from 1.0 to 1.1, 1.2, 1.3 etc. will be considered as addons made for the original plugins, while 1.0 to 1.0.1, 1.0.2 etc. will be considered as fixed version of the original.
- Everything beyond 1.99 aka 2.0 is a complete new version. So for me 2.0 would be the same as FO3 in comparison to New Vegas...a complete new game

I just was curious how you guys handle this, because every while and then I see mods with version number 8.0 or so uprising.

For me it's:
0.x to 1.0 is still alpha/beta - the mod is still lacking the basic features I want it to have.
2.0, 3.0 etc. are basically milestones - when I feel I integrated enough features into it to call it the next big thing; good for planning ahead on what major features you intend to add
1.1 feature I wanted to integrate - it adds a new feature
1.1.1 minor feature or improvement or fix) - more light-weight than a new feature
1.1.1a a hotfix for an existing something - might blend in with the above


I generally tend to avoid the use of revisions number since it can confuse people.

"salt to taste"

There really aren't any hard and fast rules except that it's best if numbers ascend incrementally. I use 1.00, 1.01, 1.02 etc. with the actual zip file named as MyMod100.zip, MyMod101zip, etc. but the internal ESP is always MyMod.esp. Renaming the zip/7z file helps when uploading to the Nexus as it doesn't like multiple files that are named exactly the same (but it doesn't care about contents).

I haven't released any beta/alpha stuff so I usually start at 1.0. Version 1.0 is considered a complete and functional release.

+0.01 is a minor bug fix (or a few) that had to be released quickly. +0.1 could be a decent collection of bugfixes and/or tweaks to the mod. +1.0 is a complete overhaul or very large expansion of the mod.

I tend to use 1.0 (which I use as an abbreviated 1.0.0) as my initial release. From then on, whenever I fix a bug I increment the 3rd digit (i.e. 1.0.0 -> 1.0.1), whenever I implement a feature I increment the 2nd digit and reset the 3rd (i.e. 1.0.2 -> 1.1.0), and I don't think I've ever incremented the 1st digit. I might do so if I completely re-write the mod for some reason, but I don't expect that to happen often.

I use a different system for keeping track of in-dev files, so only my released files are given version numbers.

Cipscis

Since alpha versions shouldn't be seen outside the lab environment, I don't bother with numbering them. I may just make notes on the backups about where I'm at. Betas too I don't bother much with thinking of a final number scheme. Higher beta number means it's a newer build.

The rest goes like this:

major.minor.bugfix

I only consider it a major if I've revamping the basic functions or methods of the mod, or put in so many additions that the user wouldn't recognize it from the last version.

Not that we are a mod, but FOSE and NVSE use Major.Minor.Beta. Anytime new features are released we increment the major. Anytime we produce an official build we increment the minor (bugfixes usually). Anytime we produce a not-ready-for-primetime build for testing the bugfixes or new features, we increment the beta. Beta is reset with change in Minor. Minor and Beta are reset with each change in Beta. One thing slightly odd - you'll see beta builds before we release the minor/major release increment. Then when we release they get set to zero. This leads to a sequence like this:

• 1.0.1 (1.0 beta 1)
  
• 1.0.2 (1.0 beta 2)
  
• 1.0.3 (1.0 beta 3)
  
• 1.0.0 (1.0 official release)
  
• 1.1.1 (1.1 beta 1)
  
• 1.1.2 (1.1 beta 2)
  
• 1.1.0 (1.1 Official release)

In OBSE we didn't have the beta field, we had the major and the build. So official releases could be marked as the 11th build (for example) which confused people. But we now provide the ability to query whether you are running a beta build or not. And we distribute the builds from different locations on our sites, so it really isn't a big problem.

I don't really worry about it other than to make sure I increment the number each time. I never release beta or alpha mods. My mods don't get released until I consider them release worthy. I have released mods as 0.1 and 1.0, and even things in between.

The numbers I use are more for my own internal tracking of versions. My version numbers tend to be more of a build number. Every time I decide to tweak something, I make a new build. I may release a mod as 0.5, and the next one might be 0.9 if I made four tweaks in between the releases.

I see most of you people don't differ much in how you handle the version numbers. You all basically use the same framework to version your mods.

I always start with a 0.1 version mostly because I would never release untested Alpha versions. If I make small mods that are already finished at first release I still keep them 0.1 in case some bugs show up that I've missed (you never know). When I'm sure that the mod is playble without bugs, judging by user comments etc. I set it to 1.0.

So far I agree with @}{ellknight a lot:



I would count bigger mods, such as FOOK or FWE for FO3 a constant beta, simply because smaller (not annoying or easy fixable) bugs are frequently showing up. It really doesn't bother me much because I consider FO3 and New Vegas to be Beta also...just an unfinished product. I wonder if I ever played a game that was worth carrying the name "final"???

I'm sure you've played Tetris.

As long as it's clear that one version is superior or inferior to another, it doesn't much matter.

I used to use major.minor.release, where release incremented on every version.

Now I just use major.release.whatever, so Fellout is currently 1.23.456.789 and Fellout NV is 0.9. 0.x is always "work in progress" but I wouldn't release anything I wouldn't personally use, since it reflects badly on the mod and the modder so even WIP releases are worth using.

A version control system is a must, IMO, during the development phase. (SVN, GIT, Mercurial, a batch file that creates ZIP/7z files named after the current date... etc. Pick your poison.) I probably have dozens of internal revisions of my ESPs, ReadMe files and associated files. I tend to create a new revision in the VCS every 10-30 minutes depending on what I'm doing. Mostly because GECK likes to crash at the most inopportune time, so I tend to change a few things, save, commit, edit some more, repeat.

Having a VCS also gives you a good place to stuff released versions of the mod, I always version anything that gets released so I can go back to that exact point in time if I have to.

I agree with that. I often make different versions of mods and playtest them for some hours. If I like what I've created I keep it, if not, I preserve it for later use. Some things need certain gameplay testing.



Tetris? That blue square part didn't fit into the one row gap...fudging bugs...even in Tetris... :laugh:

Most people follow pretty much the same idea, but this is a definite "what?" moment. 'Initial' plans are always the BIGGEST plans

I'd call 1.0 "functional" in that there should be no obvious missing features. I also wouldn't say 2.0/3.0/etc have to be complete rewrites, but like someone else said, milestones that should feel complete to the extent of the scope of the project at that stage.