incubator-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:27:38 GMT
Hi Janne,

On Dec 13, 2007, at 2:37 AM, Janne Jalkanen wrote:

> Guys,
> we've so far been using "" versioning system.   
> This is very good, because it allows us to unambiguously say that  
> "this issue was fixed in 2.5.129".  Unfortunately, for error  
> reporting this is not very good - people get confused since we have  
> a very "gappy" revision history.  You can't report bugs against  
> 2.5.129, if all the releases you have are 2.5.10 and 2.6.0.

IMO, you should identify bugs against released code, using the  
earliest release that exposes the bug. Often, the reporter is only  
interested in one release but the bug is actually in earlier and  
later releases. So the reporter might say the bug is in 2.5.1 but it  
was actually introduced in 2.4.6. The person who fixes the bug should  
try to figure out which releases the bug applies to and update the  
jira to suit.

Bugs that are in the trunk and have never been released are more  
challenging. I'd say to report these bugs, identify them by the  
release version in the trunk and the build (svn "r") number. JIRA  
doesn't have the ability to be this precise, but does allow you to  
mark the bug as being in an unreleased version and then the text of  
the JIRA spells out the build number. For example, if the result if  
building the trunk is 2.6.1-SNAPSHOT, the bug can be reported against  
"2.6.1-SNAPSHOT r557089".

When a bug is fixed, the svn commit message should contain the JIRA  
number. Then the JIRA itself will be automatically updated to contain  
the svn revision number. The "fixed in" can be simply 2.6.1.

> This is going to be even more pronounced in the future, since the  
> JIRA system is very inflexible in this - if we put *all* our  
> interim versions into it, I think it will explode.

It is up to the team to decide how to use JIRA. If you don't want to  
put all 388 versions into it, you have to choose whether to use JIRA  
for just the first two digits, or to be more selective about what you  
call releases.

In Apache, a release is a very specific thing. It's voted by the team  
and is signed and archived and mirrored. So having 388 versions would  
keep someone very busy for a very long time. Typically, in Apache  
projects, releases are made at most every couple of months.
> For example, Andrew just committed something and marked it 2.6.1  
> rc1 - how are people supposed to know that any errors are supposed  
> to be filed against 2.6.0, not 2.8?  Not to mention that it's going  
> to be pretty odd if the first release is going to be 2.6.45 instead  
> of 2.6.0...

When moving the repo and the package naming to Apache it would be  
good to decide how to do this. Other projects have a release naming  
scheme that is simply three digits, and uses the terminology - 
SNAPSHOT to mark interim releases. So while you're working on 3.0,  
the builds are marked 3.0-SNAPSHOT. This avoids the 3.0.45 problem.
> 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? ;-)

Right now, there are only two releases in JIRA (2.6 and 3.0), so  
we've avoided the issue for now.
> Also, please consider branching issues.  Currently we are branching  
> stables off the trunk, but usually only at release, or afterwards.

I'd suggest looking at release policy for other projects for ideas.  
For example, please see 
openjpa.html and  

> /Janne

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message