[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Release Management for 1.6.x

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 16 Sep 2008 21:35:28 -0500

C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> Hello all,
>> Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
>> how to avoid that situation in 1.6.x. These are some of my ideas, and
>> ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
>> release.
>> Branching 1.6.x will happen sometime during the first couple weeks of November.
>> This is flexible, but we should try to be as close to that time frame as
>> possible. If features aren't quite ready for release by that time, we'll can
>> pull 'em and they can wait for 1.7. We already have enough new features to
>> justify a release by the end of the year.
>> As soon as the branch happens, I'll roll 1.6.0-pre1.
> Does this imply that CHANGES will be up to date at this time? I ask because
> it would be a great help to the book maintainers if CHANGES was up-to-date
> ASAP so we can begin documenting the new release stream.

Ideally yes, but I don't think we should require CHANGES (as well as the release
notes, etc.) to be complete until the first RC. After all, if a tarball doesn't
have an appropriate CHANGES file, it isn't ready for release, and therefore
shouldn't be a release candidate.

But generally, I agree that the sooner we update CHANGES and the release notes,
the better.


Received on 2008-09-17 04:35:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.