commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [cli] VOTE: release 1.0.1
Date Thu, 07 Jul 2005 09:41:20 GMT


Simon Kitching wrote:
> 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.

I suspect we'll have to agree to disagree here. Sure, merging could 
retain more information out of the box but that simply puts the onus on 
the committer to create a useful commit message when performing the merge.

> 
> 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.

Yeah, fair point... done.

> 
> 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.

Hmmm, don't rememeber seeing it explictly stated when I read the doc 
last but its certainly there now.  "Theres a helluva lot to take in" 
doesn't stand up as a great defence but it I guess it was a simple case 
of over looking it.


Rob

> 
> Regards,
> 
> Simon
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

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


Mime
View raw message