incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olaf Kock <ok...@abstrakt.de>
Subject Re: Version numbering
Date Thu, 13 Dec 2007 11:53:13 GMT
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.0.build-42
 1.0.1.internal-build-49
 1.0.1.build-54

(trailing numbers are incremented by the build server)

Hope this helps,
Olaf

Mime
View raw message