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

Re: Subversion 1.5 Release decision?

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Wed, 21 May 2008 22:30:51 -0700

Mark Phippard wrote:
> On Wed, May 21, 2008 at 5:53 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>> Mark Phippard wrote:
>>> Have we reached any consensus or made a decision on the release? I
>>> think the conversation has stalled but maybe it has continued off
>>> list. It seems like we have these options available:
>>> 1) Release 1.5 the week of June 2 based on current RC5
>>> 2) Release RC6 next week based on a new branch from RC5 + selected
>>> safe fixes and API changes. GA to follow by a week.
>>> 3) Release RC6 next week based on current branch and start a new soak
>>> period.
>>> I am not in favor of #3 if we are talking about a full 4-week soak.
>>> I'd be OK with 2 weeks, in fact that option would be my personal
>>> preference.
>> Since when is any Subversion release tied to a particular schedule? And why
>> halve the soak period just to meet that schedule?
>> Reading the above doesn't make me at all happy. It implies there's an
>> implied schedule somewhere that did not originate within this project.
> The only schedule is that we are clearly near the end of the process
> and the above dates were already tossed out by our release manager and
> discussed in another thread. No one is saying that it has to be out
> by X. But I think it is reasonable to be asking what our plans are so
> that we can all set expectations. Speaking personally, I have to
> produce binaries for four different operating systems and coordinate
> the testing effort etc. I want to know what our best effort thoughts
> are so that I can plan and request the resources I need. Whether it
> be 2 weeks from now or 4 weeks from now. Is that somehow
> unreasonable?

The dates I proposed initially were based upon the release process as
defined in STATUS, nothing more. I was just trying to give people a
heads up to avoid any surprises when I cut the final RC. I'm flexible,
and as of right now I *am not* planning on cutting the RC this weekend.

> As for halving the soak period that was just one proposed option.
> Clearly we cannot wait for every bug to be resolved + 4 weeks. We
> have never shipped a release without known bugs. I'd be fine going
> with our current RC5. The main issue is that some API ickiness was
> found and cleaned up. If we fix it now we do not have to support the
> ickiness. So that opens the door for an RC6 at which point we have to
> at least consider some of the other bug fixes that have been
> backported. I think most of them can wait for a 1.5.1 but I also
> think our policies are no longer productive or accomplishing the goals
> if we want to add 4 more weeks just to get these fixes that have been
> queued up. As I said in the other thread, our policy is ironic in
> that if we fix the bugs before release, we have to resoak for four
> weeks. Yet if we ship the release with known bugs that are fixed, we
> can release a 1.5.1 with zero days, let alone weeks, of soak.

Our release and merging process is largely self-governing. When we
start the soak, the idea is that we limit our merging to the branch to
"conservative bugfixes" and use the time to find "showstopper issues".
Because these are ideally the only things going in during the soak,
rolling the final RC one week before launch shouldn't be a problem. In
fact, it should take about the same effort as a patch release.

I think that a number of people were assuming that RC 5 would become
1.5.0. That's never been my understanding; I've been working under the
assumption that RC 5 would allow people to discover problems and
contribute conservative bugfixes, and that RC 6 would be rolled a week
before 1.5.0, per HACKING. Because of our self-policing, we should be
able to roll an RC 6 at any time after RC 5.

Theoretically, 1.5.x is only becoming more stable as we progress. I
remain unconvinced that this is the case. I think a lot of people
(myself included) have merged more than conservative bugfixes and
showstopper problem fixes to 1.5.x since RC 5. I think we need to
exercise a bit more restraint here, and Karl's review of stuff merged
since RC 5 is a step in the right direction.

If we do roll RC 6, and then give it a two-week "soak", per HACKING,
it's really only a one-week soak, because of RC 7 coming a week before
the end of the two weeks. RC 7 would then become the final. The
alternative, IMO is to roll RC 6 early next week, and deem it the
precursor to 1.5.0, but wait two weeks to find showstopper bugs.
Anything besides a showstopper bugfix would be pushed to 1.5.1. RC 6
would then become 1.5.0 around June 9.

I've got no problem rolling another (or another, or another) release
tarball, until we get things Right[1], but let's be a little more
conservative about what absolutely, positively has to be part of 1.5.0.


[1] Right does not imply bug-free. It simply means that we've reached a
consensus about what to release which we feel happy about.

Received on 2008-05-22 07:31:14 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.