jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Version numbering
Date Sat, 15 Dec 2007 22:49:56 GMT

On Dec 13, 2007, at 12:24 PM, Janne Jalkanen wrote:

> With SVN, the entire repository has a single "build number".  It  
> should be possible to embed this in Release.class somehow.

Yes, OpenJPA does this.

> Of course, it will increase whenever someone even breathes at the  
> repository, so it's not really indicative of any changes.

I don't think this is really an issue, even though from JSPWiki's  
perspective, there's nothing different between svn revisions r668409  
and r668578. You can get the same JSPWiki code base from svn by  
asking for any of these revisions to be checked out.

> I like a manually updated "build number", since it's indicative of  
> when something actually really changes.

If you can embed the build number in the code this can also be useful.
> 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"  
> number.

Yeah, bumping the rc number is good, if I understand you correctly.  
You might try to release 2.6.0 by cutting a 2.6.0-rc1 and if there  
are problems with that, 2.6.0-rc2... and finally release a 2.6.0- 
rc34. ;-)

A related issue is the naming of the directories. You've already  
noted the "incubating" requirement, but the release artifacts should  
not contain -rcxxx. The builds that you vote on will contain the  
rcxxx in the directory, but internally it's not rcxxx but 2.6.0 build  
yyy. For example, release candidates might be posted at http:// 
people.apache.org/~jalkanen/2.6.0-incubating-rc2. The only place that  
rc2 appears is in this directory. The release candidate bits contain  
the final numbering scheme, e.g. http://people.apache.org/~jalkanen/ 


> /Janne
> 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  
>> Release.java and  make sure we can get people to report it in JIRA.
>> Andrew
>> On Dec 13, 2007, at 6:53, Olaf Kock <okock@abstrakt.de> 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.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

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message