Re: Proposed release process/plans
- From: Havoc Pennington <hp redhat com>
- To: jacob berkman <jacob ximian com>
- Cc: desktop-devel-list <desktop-devel-list gnome org>, gnome-hackers <gnome-hackers gnome org>
- Subject: Re: Proposed release process/plans
- Date: 10 Jun 2002 15:00:57 -0400
jacob berkman <jacob ximian com> writes:
> sadly this totally missed the issue i brought up last week... of 2.0.0
> vs. 2.0.1 in CVS. (un)fortunately it's becoming less of an issue as
> people are doing 2.0.0 releases. as long as people tag these, we can do
> a 2.0.0 branch (for minor bug fixes until 2.0.1 is out) as needed.
> in fact, it doesn't mention 2.0.x.y releases entirely.
> did you guys discuss these types of releases at all?
Most of these discussions preceded your question I guess.
In any case, AFAIK right now Michael has been doing:
What was discussed and what I intended to write down in the document
is that the long term structure we want is:
- 2.0 branch ---------- 2.0.x tag ----- 2.0.x+1 tag ---- 2.0.x+2 tag
Luis pointed out that there is some controversy over when this "2.0
branch" begins, what I'd written down is that it begins with 2.0.0,
and what other people thought is that it begins with 2.0.1. The issue
here is whether we have a place for 2.1.x development to occur during
the 6 weeks after the 2.0.0 release. If we don't branch, then 2.1.x
development would be only on ad hoc branches.
I believe the official release team view at the moment is that we
branch the long-term 2-0 stream at the 2.0.1 release point, and at
that point HEAD becomes 2.1.x and is open for new features. So that
will be in 2 months or so.
The more I think about it the more I think that takes too much
momentum out of new feature development, so I guess I'd prefer to see
us create the long-term 2-0 branch in a couple weeks when 2.0.0 comes
out. Or maybe we could split the difference and branch in the middle
of the 2.0.1 effort, or let module maintainers decide (within the
guideline that they should branch no later than 2.0.1). That could be
a nice solution.
The danger of branching early is that HEAD won't be the "active
stream" (not in tinderbox and people won't necessarily be paying
enough attention) and we could get some dubious destabilization there;
but hopefully people are mature enough not to do that. I really hope
2.2 builds on 2.0 with new features like file selector and media
player, rather than churning up the existing UI/code too much.
There's also some danger of not enough bugfixage on stable, but
really, if we're going to be Locked on stable 6 weeks post-release,
there can't be a lot of churn there. At some point zero-changes is
more useful than fewer-bugs.
Anyway, for the immediate question tagging 2.0.0 and branching it as
required ought to be fine... though in the long term having a separate
branch for all 2.0.x releases seems like overkill to me.
Probably if you want an officially-sanctioned answer you have to wait
for the release team meeting.
] [Thread Prev