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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
