Release schedule plans
jake at bugzilla.org
Wed Jan 12 01:02:42 UTC 2005
David Miller wrote:
> 1) Should we abort the 2.20 freeze and make our March 15 freeze be for
> 2.20 instead of 2.22?
I don't think anybody would be surprised to hear that I'm in favor of
doing this. I think an RC for the next version being released at the
same time as a long awaited current stable isn't really a good idea.
That does raise a question. What major features are contained in 2.20
that aren't in 2.18? I've seen it suggested that the whining patch is
about the only one. It's a nice feature, but IMHO the UI could use a
little work. It's my opinion that a few more features and a little more
time between 2.18 and 2.20 would be a good thing.
> 2) Should we attempt an "eased transition" into the 6 month cycle
> where we start at 12 months between 2.18 and 2.20 (freezewise - 2.20
> would freeze March 15 as above), then 9 months for 2.22 (making it Jan
> 1 2006), then 6 months from there on out?
Personally, I'm not even sure if 6 months is the ideal release cycle.
But more on that in another message. If 6 months is decided upon, then I
don't think we'd necessarily need an "eased transition." This mostly
seems to be a way to cover up our overlapping feature freezes. Perhaps
the best thing to do would be to simply "un-overlap" them (eg, reopen
the trunk, do a March 15th freeze [if that's the date you want], and
move on with life).
> 3) Our newly frequent releases (if we can stick to them) are going to
> create a lot of branches to simultaneously maintain. Should we have
> branch managers for each branch?
I guess the big question I'd have is: what's the benefit of a branch
maintainer? Is it just somebody other than Dave that can say whether or
not a specific patch can land on that particular branch? I suppose that
could be a useful thing, especially if we end up supporting a lot
branches at the same time (more in another message, again).
> 4) b.m.o upgrade schedule was discussed.
I do like this idea, though I'm also in favor of Gerv's suggestion of
doing the upgrade right after the feature freeze but before the branch.
That would give roughly a two week time frame in which nothing could
land on the trunk except for bug fixes before we branch for a new version.
> 5) What kind of branch lifetime and support level should we provide?
Now this is one of those interesting questions in life. The ongoing
battle between software coders who want users to constantly be enjoying
the newest features and the administrators who actually have to go
through the pain of upgrades. So the real question here is, how often
should we "force" somebody to upgrade. And how compatible is this with
other means of distribution than downloading it via bugzilla.org. For
example, I've seen some things recently where Debian's stable distro is
in need of security patches, but it's something we abandoned long ago.
Perhaps branch maintainers will help solve this problem. We tell them
what our minimum support time is and if they want to continue to support
it after that (because it's still being used somewhere special), that's
entirely up to them.
> == Bugfixes provided
> -- Security only
> Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
> 2.16 --|
> 2.18 ======-----------|
> 2.20 =======-----------|
> 2.22 |======-----------|
> 2.24 |======-----------|
> 2.26 |======-----------|
> 2.28 |======-----------|
Obviously, part of the problem that's going to be causing us to have to
support 6 branches at the same time is the overlapping feature freezes
which is the who point of this discussion. If we do away with that and
simply normalize right now, we'll only need to support 4 branches at
once (which is still a lot).
More information about the developers