Greg Stein <gstein@lyra.org> writes:
> No. Those guidelines are necessary to create some kind of sanity in the
> upgrade/compatibility process.
Sure, I agree we need *a* guideline for the process. I'm asking, is
*this* guideline the best, or is there a better one for our purposes?
> If you upgrade SVN from 1.0 to 1.7, then all applications will continue to
> function properly. No need to update them. Any 1.x release provides all
> the entry points, signatures, and semantics of the prior 1.x releases.
>
> On the other hand, if you create an application that requires
> functionality from 1.4, then you will need to update that SVN 1.1
> installation to 1.4. But this is a safe thing to do, per above. That
> upgrade will not break other applications.
Okay, you're explaining the current guidelines. But as long as
there's *some* guarantee, where one can look at two version numbers
and know the degree & kind of difference, that will be just as good.
For example:
If you upgrade SVN from 1.2.3 to 1.2.4, all applications will
continue to function properly. But maybe if you upgrade from 1.2.3
to 1.3.1, that won't be the case.
That's a different guideline from what we're currently using, but it's
perfectly consistent. The APR versioning scheme is just one of many;
we're free to use another that suits us better.
> Part of the problem here is the conflation of using the version number to
> describe feature enhancements ("2.0 has a lot of wicked cool new
> functionality") and binary compatibility ("2.0 has a few minor feature
> enhancements, but the API was drastically revamped").
Yup, that's what I said too.
But that conflation is inevitable. It is the very reason why we'd be
reluctant to release 2.0 (say) six months after 1.0. Even though we
might have a lot of API changes batched up, we'd feel there was
something wrong in releasing 2.0 that quickly -- we'd feel we'd look
bad, and we'd be right. 2.0 should include major new features.
So why are we trapping ourselves into this? We could separate API
breakages from wicked cool new functionality, and then we could make
each kind of release when it was ready, instead of waiting for when
both are ready (which always means delaying one of them).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 07:38:44 2004