Ben Collins-Sussman <sussman@collab.net> writes:
> (Karl's opinion, which I now agree with, is that it's a bit too harsh to
> demand that people upgrade to 1.1 the instant it's released.)
That's actually not what I said. I proposed that folks would upgrade
to 1.1 only if we fix a critical bug (since we wouldn't have
backported that fix to 1.0.x).
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.
But I don't feel so strongly about any of this that I'll debate it any
further. Just making suggestions. :-)
---------------------------------------------------------------------
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:39:11 2004