incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: Version numbering
Date Thu, 13 Dec 2007 20:24:22 GMT

With SVN, the entire repository has a single "build number".  It  
should be possible to embed this in Release.class somehow.  Of  
course, it will increase whenever someone even breathes at the  
repository, so it's not really indicative of any changes.  I like a  
manually updated "build number", since it's indicative of when  
something actually really changes.

And actually, now I think about it, I think SVN's version number is  
common to the entire repository, so it will increase even if someone  
updates another project...  I don't think that's a very good indicator.

Of course, our development branch does not really care.  We could  
still be running 2.7.1, 2.7.2, etc, and say it's "2.7.x" in the bug  
reporting tool.

Apache will require us to put the word "incubating" in it, if we  
release before moving out of the incubation process, so we'll have  
somewhat interesting release names... 2.7.234-incubating build 3943 ;-).

Also, we have to think about branches.  Should a build number be  
unique across all branches, or should it be something which is used  
within one branch only?  (i.e. is it possible to have 2.6.1-14,  
2.7.1-14, and 2.7.4-14?)  If it's unique across all branches, it'll  
end up being gappy, and then it must be automatically allocated, or  
developers will need to keep manually track of the latest build number.

Nevertheless, I'd like to propose that with 2.6, we *don't* up the  
release number anymore - 2.6.0 is the first released version, 2.6.1  
is the next one release and so on.  Let's keep bumping the "rcxxx"  


On 13 Dec 2007, at 16:36, Andrew Jaquith wrote:

> Olaf has the right idea.  Keep the version numbers and build  
> numbers separate.
> A good example is Parallels. Every downloadable version offered to  
> the public has a major and minor version number: 3.0, 3.0-rc1, etc.  
> There's also a build number: 4128, 5150, 5370.
> From the standpoint of release control, the rules would proplably  
> work like this:
> - every time a committer checks in a batch of stuff (code or  
> otherwise), they must increment the build number
> - the release number is only changed upon stable releases, or at  
> the pleasure of a benevolent dictator (Janne)
> All we really need to do, then, is add a build number field to  
> and  make sure we can get people to report it in JIRA.
> Andrew
> On Dec 13, 2007, at 6:53, Olaf Kock <> wrote:
>> Janne Jalkanen schrieb:
>> [...]
>>> Anybody have any suggestions?  I would very much like to retain the
>>> ability to clearly say which "build" has what (as it, among other
>>> things, encourages us to do small, stable commits, which are good  
>>> for
>>> overall project stability), but error management is going to be a  
>>> bigger
>>> hassle in the future.
>>> Of course, if there are JIRA wizards among us, they could perhaps
>>> suggest an alternative method of release management? ;-)
>> I don't know if I count as JIRA wizard, but I'm quite happy handling
>> version numbers and builds as distinct information. Therefor a  
>> version
>> is whatever is voted stable and deserves its own (manual) numbering
>> scheme. The build number is issued by our continouus integration  
>> server
>> which boils down to every single commit resulting in a new build  
>> number.
>> Issues are usually reported against version numbers, but may be fixed
>> with a remark like "fixed in build 1234" (but flagged fixed for  
>> the next
>> to be released version).
>> If somebody insists, the "fix build" may be saved as a custom  
>> field in
>> Jira, we are usually just entering it in the fix comments. (Nobody  
>> has
>> ever wanted to have a report of fixed issues per build number)
>> This gives best of both worlds: Nobody gets confused about why  
>> 1.0.42 is
>> a must-have while 1.0.49 is a risky build. For customers the CI- 
>> server
>> flags almost all builds as "internal build" (and the build number is
>> displayed in the application, so it is known to be unsupported) while
>> release versions get their labelling changed.
>> Our typical label numbering scheme is something like this:
>> 1.0.1.internal-build-49
>> (trailing numbers are incremented by the build server)
>> Hope this helps,
>> Olaf

View raw message