Ben Collins-Sussman <sussman@collab.net> wrote on 06/07/2004 01:46:00 PM:
> On Mon, 2004-06-07 at 12:37, C. Michael Pilato wrote:
> > 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. :-)
>
> Definitely some advantages to that approach... like, predictablity.
>
> But a disadvantage is that it "ties" our support burden to releases. I
> mean, what if, for some reason, Subversion 1.2 doesn't come out for a
> *year*. Now we're obligated to support 1.0.x, even when 3 people are
> left using it?
>
Just because 1.0.x is supported doesn't mean every fix would be back
ported. Presumably only something major like the recent security fix, or
some new data-loss scenario and fix would be back-ported, or just some
other fix that was really popular or asked for. I think the key is just
letting user's on 1.0.x know that if something major comes up there will
still be support.
I think an important point to document and define will be compatability.
Can I mix a 1.0 client with a 1.1 server and vice versa? Those are the
main issues people will want to know and will make it easy or difficult to
upgrade depending on the answer. You talk a lot about API contracts and
compatability on this list, and that is important for people working at
that level, but I think most users are more concerned about the far
simpler question like: can I upgrade my server to 1.1 and fsfs and still
use a 1.0.4 client? I think the answer is Yes, but as long as you are
using a 'server', but some kind of clear compatability matrix would help.
This might also extend into guarantees for the future. Can we say that a
1.2 server would be compatible with a 1.0 client, etc....
Definitely in favor of a 1.1 though.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 20:01:54 2004