OSDev.org

..

Hm ...

I am using the m.[x][y][z]-[date] scheme, where
m = Major Stable Release.
x = minor stable release
y = major beta(or alpha) release
z = bug fix and feature addons release

sometimes, when I consider only the added feature or bugfix be worked over or the added feature isn't sooooo impressive to need a version number, I just leave the version number the same and add the release date to the version string. My bash-saving scripts are doing that too: simply add the actual system date to the filename.

I don't know if thats good but it works for me.

Perica wrote:
Anyway, what convention do you think is the nicest (please explain it, don't just simply post a number demonstrating the convention - explain how it goes about incrementing the version number for bug fixes, feature add-ons, multiple major feature add-ons, et cetera).

version.revision.

I had written up a lengthy paper on this for Pro-POS, which went to the trashcan during the Pro-POS takedown earlier this year.

The idea is that your "product" (application, OS) has a version.revision number (e.g. 3.1). Version indicates major jumps in functionality, revision indicates bug-fix and minor feature-adding releases. (I don't believe in "release early, release often", so I don't need anything more fine-grained.)

Such a product is composed of various files (executables, libraries etc.), which again have version.revision. Files belonging to a given release of the product (e.g. 3.1) all have the same version number (e.g. 40.x - any component belonging to product v3.2 would have 41.x), with the revision number incremented when the component in question is touched.

The details of it in regards to internal (developer) versioning (alpha / beta labelling, patch releases etc.) are a bit too much to elaborate on at this point. I'll see if I have a copy of that paper flying around somewhere still.

The idea is to have versioning so short and crisp the user can keep the version in mind with little trouble (i.e., no 2.54.3654.1523 beta), and that from looking at a component you get an idea which version of the greater product it belongs to.

Alpha, Beta, patch levels etc. are for internal, developer use, and the user should be "protected" from them.

As always with ideas from me, credits to the Amiga for introducing me to the concept.

x.y.z

x = main version, this is only incremented when I rewrite the software from scratch.
y = update, this is only incrimented when I add new features or make major changes to the software.
z = bug fixes, this is only incremented when I fix bugs in it.

I have wondering about this very same subject myself. As my OS gets bigger and bigger I need to manage it better. Solar I certainly appreciate your input here. I'd love to see your document on this subject. Out of curiosity, internal versioning is really what I'm curious about. I've been considering adding on to Major.Minor with a .Build in order to recognize changes between builds (or assemblies/compiles) for each file.

Out of curiosity too, I've heard of CVS (I've yet to look at it), are there any software management packages out there that will increment build information on the fly? In otherwords, for each compile/assembly time it will it modify a build number and then compile (archive et al)?

Thanks!

Here is the scheme I use at work:

major.minor.build.revision

e.g.: 3.1.205.0

major = Any number, although in practice it takes a long time to reach 10 and higher. Changes when a large architectural change occurs.
minor = Any number, although in practice "major" is incremented before "minor" reaches 9. Changes when new features are added.
build = Any number. Incremented for each "official" build that is thoroughly tested and shipped.
revision = Any number, although in practice it is almost always 0 and rarely gets above 1. This represents a minor correction to an official build that does not require full regression testing.

i do major.minor.build

there may be no difference between 1.1.203 and 1.1.903

my build numbers roll automatically.

api changes between minor version numbers, you can add new calls but cant change any existing call interfaces.

smiddy wrote: Out of curiosity, internal versioning is really what I'm curious about.

Well, actually you have three levels of versioning: Product, components, source files.

I've been considering adding on to Major.Minor with a .Build in order to recognize changes between builds (or assemblies/compiles) for each file.

You would have to reset the build number whenever you bump Minor... and build number as such is pretty meaningless since it could be just another build of the same sources or a complete rework. You would also be unable to use the build number information to return to that very version in your source tree, which is why we do versioning in the first place.

Out of curiosity too, I've heard of CVS (I've yet to look at it), are there any software management packages out there that will increment build information on the fly? In otherwords, for each compile/assembly time it will it modify a build number and then compile (archive et al)?

Subversion keeps a repository-global revision number. Every edit to the repository bumps the revision number, no matter which branch or which files are affected. Much more meaningful than a "build number", and it makes individual file versioning much more manageable than CVS, where individual file versioning is a real PITA.

that reminds me since i forgot (its automatic).
at the end of my major.minor.build is a /subversion version...

which can be a "/234" or "/234:240" or "/234M" etc. depending on the source state...

I use the x.y.z.a notation.

X : Main product version, at 0.0 (begin) you define what 1.0 should be. When you reached that, you begin to think up a 2.0, and work to that in the next levels.

For each major verison I define a number of steps to get there. These steps are all still quite steep, such as "make an environment in which a userlevel program runs" for my OSes 0.1. These are then subdivided into problems such as "make an environment in which kernel threads can be started", "add kernel processes", "add a module interface", "create driver modules", "create userlevel access", all together accomplishing the 0.1 goal. These are then 0.0.1, 0.0.2, 0.0.3 and so on. From these I continue with 0.0.1.1 or 0.0.2.1 if there is a need for upgrade for the version to be usable, or it constitutes a big advantage over the old method and doesn't require much backporting from my working copy. I usually release only each x.y.z version.

Yes, the module part is taking quite a while, mainly because I don't have any time (at all).

Solar wrote: Subversion keeps a repository-global revision number. Every edit to the repository bumps the revision number, no matter which branch or which files are affected. Much more meaningful than a "build number", and it makes individual file versioning much more manageable than CVS, where individual file versioning is a real PITA.

Thanks a ton...I'll have to sit down and learn how to set this all up in between bouts of coding...

Hint: Even if it sounds nice, don't go for the Apache-integrated setup; use the standalone server. It's easier to set up, especially for a limited-scope project.

I'd also advise using the FSFS backend instead of the BerkleyDB if you're running on a Linux machine. Version dependencies etc. can be a ***** with Subversion, as updating the BerkleyDB can render your repository unaccessible.

yea i run the standalone version (i do have apache but i dont use the mod_svn/mod_dav etc)..

once you create the repo with svnadmin its so simple. svn status/svn ci -m "blah" / svn co...

Solar wrote: Hint: Even if it sounds nice, don't go for the Apache-integrated setup; use the standalone server. It's easier to set up, especially for a limited-scope project.

I'd also advise using the FSFS backend instead of the BerkleyDB if you're running on a Linux machine. Version dependencies etc. can be a ***** with Subversion, as updating the BerkleyDB can render your repository unaccessible.

I've just started looking at Subversion, I'll keep that in mind.

srg

FWIW, that versioning paper of mine is digital history (i.e., trashed beyond repair). I'll just write up a new one.