Versioning

[eluser]zdknudsen[/eluser]
I have been wondering what's best practise regarding version numbering. First of all, how should one number ones releases?

Should I release, and then do changes to the current release when finding bugs, or should each bugfix result in a new release?

And a thing I have found tedious in a few of my projects; docblock-info shared across all my files, like version number, author, etc. Is there a way in which one could have this data automatically inserted into the files through e.g. SVN, Eclipse (the program im using), etc.?

[eluser]gtech[/eluser]
I think version numbering varies from company to company (remember netscape jumping from v4 to v6). As far as I am aware there is no standard. One example I can think of

0.1 development before testing
0.2 development after testing (bug fixes feature requests)
0.3 ....
0.4 etc

then

1.0 when ready for release
1.1 bug fixes/feature requests
1.2 ...

release 2.0 maybe a redesign of the code, or a large variety of new features..


as for automatically inserting user-name etc through SVN I found this link as I want to do the same, I am a bit tired and only scanned it, but i'm hoping its what you need?

[url="http://myeasyscripts.com/loudbaking/category/coding/"](DocBlock and svn:keywords)[/url]

[eluser]Michael Wales[/eluser]
A version less than a full integer is a minor modification - bug fixes, security updates, etc (0.1 -> 0.2, 2.0 -> 2.3).

A version of a full integer is a major modification (usually a rewrite of the entire codebase) 1.0 -> 2.0

Some business use a 3-place numbering system (like, Mozilla, 2.0.3): 3 would be a security update, 0 means there have been no major revisions to the codebase, and 2 means it's the 2nd rewrite of the application as a whole.

[eluser]Jim OHalloran[/eluser]
I generally use a 3 place numbering system... Which I use as major.minor.release. I bump the release number whenever bugfixes are made (1.0.0 + bug fixes is released as 1.0.1). Bump the minor version for feature enhancements (1.0.1 + new features is released as 1.2.0). Increases in major version are reserved for redesigns, rewrites and major new features (i.e. 1.2.0 when rewritten is released as 2.0.0).

A 1.0 release indicates "stability" in a lot of people's eyes. I always want to releasse 0.x versions until I beleive the app is reasonably stable, but I think it's important to get to 1.0 as soon as possible. That may mean releasing 1.0 in a stable form with a smaller featureset, then following up with 2.0 once the originally planned featureset is done.

One thing I think you always want to avoid is having two different releases with the same version number. Even the smallest bugfix should get a new version, otherwise it's really difficult to track ("have I got the old 1.0.1 or the new 1.0.1", vs "I've got 1.0.1 and 1.0.2 has just been released").

As far as managing all this in code goes, I usually Declare the current version number as a constant in a configuration file (or similar) which then gets included into every script. I try to avoid using version numbers, etc in docblocks to avoid changing those with every release. You can get the current revision number from subversion, and use that as a constant in your code, but that's not as useful as it seems (I tried it once on another project and it was a bit awkward to manage).

Hope that helps.

Jim.

[eluser]xwero[/eluser]
I try to use some sort of 'versioning' logic but i can't find the right logic either. It's difficult to decide how much a version can jump after changes.

Maybe you could use a simpler version logic in the form of dates. It's not as short as 1.0(.0) but the version is crystal clear. You could even pinpoint the releases by the minute, by the second would be a bit too much i think.

[eluser]zdknudsen[/eluser]
I see the logic in increasing the version with each bugfix, so I guess that's the way I'll be going.

However, the link you presented me with gtech, only contained information of which i was already aware. I actually use one of the SVN keywords, namely the $Id$ one, which contains information about the date and author for the last revision. But what I wanted to was to automate the making of the whole docblocks (or at least just the version number), so you could somewhere update your current version and all the files would use that number.

[eluser]gtech[/eluser]
Have you thought about using tags in svn? if you are not aware tags enable to create a version number for the whole project in a repository. That means the state of all the files is recorded at that point in time and given a version number. This means you can checkout different releases at a later date.

its only a theory but you might be able to insert the tag number into all your files from svn. Hey it may even appear in the $id$?

[edit] you can also branch off tags so if different customers start to have specific requirements you can keep 2 revisions from the same point in time.[/edit]

Failing that maybe you could write a script that directory walked your project and do a simple regular substitution on each file.

[eluser]gtech[/eluser]
(read post above)

As the version is recorded in SVN using a tag (CVS,SCCS does the same) you may not need to put it in the comment. You can just have a directory for each version (thats what i have been doing most my life)

[eluser]zdknudsen[/eluser]
So how would I use the tagname as a keyword in my files?

[eluser]Leggy[/eluser]
I use 1.0 for the first version

1.0.1 - bug fixes
1.0.2 - bug fixes

1.1 - new features
1.1.1 - bug fixes
1.1.2 - bug fixes and maybe some new features

2.0 - complete new version.