On Fri, 2003-12-19 at 13:38, Justin Erenkrantz wrote:
> --On Friday, December 19, 2003 12:17 PM -0500 Greg Hudson <ghudson@MIT.EDU>
> wrote:
>
> > There most definitely was opposition from me to the idea of keeping the
> > release version and the shared library versions in sync, and I think the
> > people who support it don't realize all the ramifications. (Justin
> > might realize the ramifications, but if he does, he hasn't put forth a
> > complete proposal yet.)
>
> Oh, stop with the personal attacks. It's not warranted.
You've proposed a constraint: our library ABI versions should be all
tied together, that ABI version should also be tied to the Subversion
release number, and that snapshots, testing releases, and and private
builds must adhere to the version-numbering constraints as stable
releases. This constraint has some far-reaching implications for a
project with multiple libraries and with non-library components:
* We release Subversion X.Y.Z and then make massive (possibly even
incompatible) changes to the command-line client, or add a significant
new feature, but do not change the library API. We must now choose
between releasing Subversion X.Y.Z+1 even though there are significant
new features, or releasing Subversion X.Y+1.Z and forcing unnecessary
library upgrades.
* We release Subversion X.Y.Z and then fix a security hole by adding a
new library function. We must release Subversion X.Y+1.Z or (X.Y+2.Z if
we do even/odd) even though we only made a single targeted bugfix.
* We add a function to libsvn_client, but do not make a change to the
server. The server's API version must also be bumped, forcing
unnecessary library upgrades upon people who update server binaries.
* If we do not relax the policy for trunk snapshots, then we will have
bizarrely spaced releases (e.g. stable 1.0.0 followed by unstable 1.1.0,
1.3.0, and 1.5.0, followed by stable 1.6.0, if we use odd-even).
* If we do not relax the policy for private builds, then we must bump
the trunk middle version every time we add a new library function, and
our middle version numbers for releases of any kind would likely be
spaced very far apart (stable 1.0.0 followed by unstable snapshots
1.13.0, 1.33.0, and 1.85.0, followed by testing releases 1.99.0, 1.99.1,
and 1.101.1, followed by stable 1.102.0).
Confusingly, you have typically argued for this constraint in response
to specific aspects of other people's proposals, even though accepting
the constraint would mean essentially scrapping any such proposal
(Karl's or mine) and starting over from the APR versioning system.
When I complain about this mode of presentation, you accuse me of making
personal attacks! To me, that's a serious accusation. It should be
perfectly fair game to criticize the way someone is making an argument
if I think it's detracting from our ability to come to a well-considered
consensus.
> I've yet to be convinced that your proposal is helpful to any
> third-parties or users.
I think it's helpful because:
* Stable releases are versioned according to whether they have made
major changes, minor improvements, or only bugfixes relative to previous
releases, allowing people to make reasoned upgrade decisions without a
lot of research.
* Unstable snapshots, testing releases, and private builds clearly
indicate their source (trunk revision or branch and revision) without
disturbing the namespace of stable releases.
I didn't invent this kind of versioning. It differs from dozens of
other projects only in the details. (The same could be said of Karl's
proposal, of course.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 20 01:52:45 2003