ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: Ant 1.6.3 [was status report on the PMC list]
Date Wed, 25 Aug 2004 09:18:15 GMT
Stephen McConnell wrote:
> What is the criteria that is use by the Ant project for a major, minor,
> and micro version bump?
> 
> Stephen.
> 

This is my opinion.

A major version number increment represents a change in internal 
architecture. At such a transition some level of backwards compatibility 
breakage would be acceptable.

A minor version increment is associated with the release of new features.

A micro version increment is associated with bug fixes of existing features.

These are not hard and fast rules. The distinction between a new feature 
and a bug fix is not always clear. Sometimes we break compatibility in 
small ways even at micro version changes.

Over time, the thought of a major achitectural change has receded. The 
whole Ant2 exercise used a lot of energy. In any case many concepts from 
that time have made their way into Ant in an incremental fashion (and 
yes, they have potentially broken compatibility at the code level if not 
at the build file level). At one time we considered making the major 
release change correspond to a JDK dependency change but we went to JDK 
1.2 without changing to Ant 2.0.

It is interesting to note the historical correspondence between these 
increments and CVS

Architectural changes (i.e. major version changes) start out as separate 
proposals (none so far being adopted).

minor version changes are CVS HEAD branch points

micro version changes are releases on the branch.

My original idea for branches was that bug fixes would be applied on the 
branch only and not to CVS HEAD. At branch release points (micro 
releases) or sometimes sooner, the changes made on the branch would be 
merged into HEAD. This is easy to do with appropriate use of CVS tags. 
New functionality would be developed solely on HEAD.

In reality, this is not so easy. A lot of Ant users actually use HEAD 
for their Ant builds and rebuild often. These people, often Ant 
committers, want to have bug fixes as soon as they are available. In 
effect both HEAD and the branch are actively utilised. Fixes are thus 
applied to both branches. This duplication of work can be a pain and 
also can cause changes to be missed - in either direction. The longer 
the branch lives the more painful it is. The piecemeal merging without 
appropriate tagging make a larger merge more difficult.

The choices I see for branch management are:

1. Keep going the way we are now - i.e. applying changes to both HEAD 
and the active branch.

2. Keep going as we do now but make sure branches are shorter lived. The 
   impact of this would be to have fewer micro releases and more minor 
releases. i.e. instead of Ant 1.6.3, we would go from HEAD and call it 
Ant 1.7 even though it may not contain any significant new features.

Branches would have a life of say two months to deal with major show 
stoppers after the initial 1.x.0 release. Any bug fixes after that 
period would be made on HEAD and a release would not be made until we 
are ready.

With this approach we would have releases more often. Of course, we're 
not a company and not bound by procedures, etc. If the changes on HEAD 
require some maturation time, we could extend the life of a branch. i.e. 
in the end we do what we need to do.

3. Move to a model where bug fixes are applied to branches *only* and 
merged in a more controlled fashion either at release points or on a 
more regular basic (weekly, monthly). The advantage here is to make sure 
all changes eventually get merged into HEAD. It would probably require 
somebody to take the role of merge manager.

Conor


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message