On Wed, 2005-07-06 at 23:41 +0100, Rob Oxspring wrote: > Hi, > I've spent this evening merging changes from the trunk to the 1.x > branch, including both changes that bring it in line with the current > build system and licence requirements AND bugfixes applied to the 1.0 > code. I've lined this up as the commons-cli-1.1: > > http://people.apache.org/~roxspring/cli/distributions/ > > Alternatively we should be able to build a 1.0.1 as described below by > reverting to the old build system releasing under the old licence, but > I'm not sure if that is desirable. > > Thoughts?
I'm not generally in favour of merging between branches. As currently implemented, it loses all information about individual commits; making a dozen changes with nice commit messages then merge them into another branch and the other branch gets one huge change with message "merged" or somesuch - quite horrible for tracking down issues later. And unfortunately, Rob, building release candidates with final version numbers is also a REALLY BAD idea. Please remove the files from http://people.apache.org/~roxspring/cli/distributions/ immediately. Otherwise we have jars with -1.1 and -2.0 floating around which don't correspond to the final releases with those same version numbers. The release preparation procedures are documented via the link "General Information | Releasing Components" in the jakarta-commons site navbar. These explicitly state that the currentVersion field in the project.xml should not be set to the actual release version# until the final RC has been approved and the actual release is being prepared. See "Create the release candidate". In general, the currentVersion field should be set to "..-SNAPSHOT" or "..-dev" or "..-RCx" except when actually making a final release build. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
