C. Michael Pilato wrote:
> But I'm cool with the middle-ground approach. Being a guy who isn't
> much thrilled with so-called "fuzzy" decisions, though, allow me to
> recommend that we simply state that as a matter of policy, we will
> keep at most N maintenance branches alive. As new major and minor
> releases come out, old ones drop off the radar. If we have a policy
> regarding this, we can better plan announcements, which means users
> have time to react, and means our volunteer release managers know up
> front what they're getting themselves into. :-)
>
> For example, we we say that we'll keep 2 maintenance lines alive then
> we know that the minute we start planning the 1.2 release, we can
> simultaneously announce the upcoming end of our support for 1.0.x.
> That gives users time to upgrade -- either to the new 1.2, or to what
> should at that time be a quite stable 1.1.x. I feel that presenting
> the public with an overbearing set of releases to choose from will
> only foster confusion. "Why should I get 1.2.1 instead of 1.1.2 or
> 1.0.6?" and all that.
The mozilla project have 1.x releases with differing support plans. If
I remember, 1.0, 1.4 and 1.7 are stable lines. This means that critical
fix path for users of 1.5 or 1.6, is an upgrade to 1.7.x but that
patches are backported to 1.4.x. It allows other
distributers/packagers, and those building products on top of mozilla
code to have long stable periods while still getting stable releases
with new features out to users regularly. The status of such releases
are determined at or before release time, so this does fit your desire
for both users and release managers to see know the expectations ahead
of time.
I can't say if this is the right model for svn, but subversion is a
project which acts as a base for other GUI/integration projects. On the
other hand you already have a stronger policy on binary compatibility.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 19:57:44 2004