On Sat, 2003-12-20 at 04:15, Justin Erenkrantz wrote:
> > * 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.
>
> If we are really making incompatible changes to our command-line client, why
> would we only be bumping the patch level?
In my proposal, I wouldn't consider it. But with your discipline, we
would be forced to bump the ABI version in order to change the middle
version number.
To put it another way: Subversion 1.2.0 and Subversion 1.3.0 might have
exactly the same ABI, but a program built against 1.3.0 would fail to
run on a system with 1.2.0 installed. That seems poor.
> I want a clear contract with third-parties and our users about what their
> expectations should be regarding major, minor, and patch versions. My largest
> complaint (that I've repeated a number of times here) is that the Mozilla
> model that has been advocated does not indicate how 'big' of a change one
> version is to the next.
I can only assume from context that by "how big" you mean "how
incompatibly the ABI of any libraries has changed" (major version -->
total incompatibility, minor version --> backward compatibility, patch
version --> backward and forward compatibility). It's unfair to single
out Mozilla here; I think you'd have a hard time finding very many
multi-module projects which communicate this information in the overall
release number.
If it helps, I expect, and would be willing to mandate, that the *major*
version of shared libraries would stay in sync--you generally can't
incompatibly change the ABI of a library without also incompatibly
changing the ABI of libraries which depend on it--and that Subversion
major version number would track that number. GNOME seems to have borne
that out, at least for the core libraries.
> The model that Keith Packard has been proposing for X is that every library is
> a stand-alone release. There will be no 'X' releases any more - only libFoo
> that is a part of X. Your proposed model with separate versioning makes sense
> *if* we distribute all of the libraries independently.
Heh. I would say that *your* model makes sense if we distribute all of
the libraries independently; then a library's release number can track
the library's ABI version with little conflict. But if we have a
unified release, then tying all of the ABIs together and to the package
number is too inflexible.
> As in httpd, the Subversion 'core' is maintained by one group of people
> (namely the full committers). In httpd-land, we felt that partitioning out
> the components into discrete releases would harm the community and
> maintainership. It'd create fiefdoms that we wanted to avoid.
That conclusion seems to conflate separate releases with separate
maintainership. I would say the decision to have one versus many
releases should be driven by consideration of release engineering
resources and the user experience. (Right now the answer is almost
certainly "one release"; perhaps in the future, if the vast majority of
Subversion users get Subversion via binary packages which are part of OS
releases, the right answer will be "many releases.")
> Furthermore, over in httpd-land, we felt that if we're viewing the entire
> codebase as one complete system, then there's problems with having everything
> be disjoint. Are we planning to support (as a community) the individual
> components or the entire collection? We felt that everything in an httpd
> release is 'together' - that is, if one part is stable, so is the rest. I
> think the same could be said about Subversion.
Right.
> Finally, I'd like for TortoiseSVN (or any other third-party) to finally say,
> "We're compatible with any Subversion 1.x install." Given your choice, what
> would you say that the TortoiseSVN folks should ask for? Is it "we're
> compatible with libsvn_wc 1.0, libsvn_ra 1.0, libsvn_client 1.0, etc." So, at
> what point, does TortoiseSVN *need* to produce a new release? Is it
> Subversion 1.1? Is it Subversion 1.2? Is it Subversion 2.0? Do we know?
I think this question should be easy to answer if the major versions
stay in sync (Subversion 2.0 would mandate source-level changes to
clients; 1.x would not, although it might introduce new functionality
which clients could take advantage of). But by letting the middle
versions float, we allow for a more precise and robust determination of
ABI compatibility.
> If we say that we're going to be producing x.y+1.z releases every month, do we
> really need odd/even? Perhaps not. If we're saying longer than six months,
> then yes I think we must have an unstable versioning scheme.
I just don't see this. Other projects of our size have 12-month or
longer release cycles and there's just not much appetite for unstable
releases. They will occasionally toss out an unstable snapshot to
encourage a moderate amount of testing of some new feature, but the
snapshot is typically labelled by date, and they don't get packaged up.
> > * 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.
>
> Why? The people running the server wouldn't update. I don't understand why
> the library upgrade is a concern here.
If svn 1.2.0 and svn 1.4.0 have indentical ABIs for libsvn_fs,
libsvn_repos, and libsvn_subr, then I should be able to compile a
program against libsvn_repos in 1.4.0 and run it against 1.2.0. But
because you've tied all the ABI versions together, that wouldn't be
possible.
> > * 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).
>
> I don't understand this scenario. Where did 1.2 and 1.4 go?
I was assuming even/odd, and that we never stabilized between 1.3 and
1.5.
> Trunk snapshots are just that: 1.3.0, 1.3.1, 1.3.2, 1.3.4. As I see it, the
> binary compatibility expressed in the trunk snapshots are relative to the last
> stable version - not to the last trunk snapshot. The unstable versions don't
> have a 'fixed' contract, yet they are supposed to be fixed to the last
> 'stable' release.
That's what I meant by "relaxing the policy". This relaxation would
open us up to the possibility that someone might compile a binary
against 1.3.1, attempt to run it against 1.3.0, and experience a cryptic
failure because the rules say 1.3.0 and 1.3.1 are supposed to be
backward- and forward-compatible.
> The 1.3.x would represent the current API proposed for 1.4
> - it should be binary-compatible to 1.2 and adds new features that will be
> 'frozen' for 1.4.
> If a change goes into the trunk that causes binary compatibility to be lost,
> it's 2.0. Note that this was a major point of contention when adopting both
> the APR and httpd rules - what do we do on major version bumps? How do we do
> a dev cycle for that?
These points reveal, to my mind, a fundamental problem with your scheme:
the version number conflates ABI compatibility with the position in the
development cycle. We would bump from 1.2 to 1.3 even though there are
no ABI changes, would remain at 1.3 even though there are repeated ABI
additions, and would bump from 1.3 to 1.4 even though there are no ABI
changes, because the development cycle demands those bumps and
constancies.
> Both times, we decided to punt and deal with it when we
> had to.
In my scheme, there would be no problem:
* We'd bump the shared library major version numbers when the
incompatible changes go in on the trunk.
* Trunk snapshots and private builds would be identified only by trunk
revision, giving neither a false nor true expectations of compatibility
or incompatibility. (Which I think is fine; see below.)
* Testing releases would be identified as subversion-beta-2.0-rXXXXX,
giving a clear indication of the incompatibilty with 1.x.
* The first stable release after the major ABI change would be 2.0.0.
> > 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.
>
> And those are arbitrary decisions. You and I may disagree on what is a major
> change, what is a minor change, and what is a bugfix. I want to remove any
> arbitrary decisions from the versioning process as we'd just get bogged down
> by people disagreeing on what is 'big' or not. If the versioning is tightly
> bound to the bundled API, then I think there's little room for discussion
> about what the next version should be called; and it's clear what a version
> bump means. In my proposed model, the only thing left is to define what
> *else* causes version bumps (i.e. repos schema, etc, etc.).
I don't follow this argument.
An incompatible ABI change would warrant bumping the major Subversion
release version, in anybody's scheme. You've suggested that there is
room for argument about whether other sorts of changes (network and disk
formats) would also warrant a bump. So does your scheme make the
decision any less arbitrary?
> > * Unstable snapshots, testing releases, and private builds clearly
> > indicate their source (trunk revision or branch and revision) without
> > disturbing the namespace of stable releases.
>
> As has been repeated several times by others, revision numbers (rXXXX) are not
> practical for use by Subversion itself in reporting a version. And as I have
> said before several times, I don't believe there is a meaningful way to map
> the monotonically-increasing revision numbers into versions that indicate any
> type of compatibility.
And as has been repeated several times by others, they don't have to.
These sorts of builds are not for mass consumption. Their users almost
always have context, because they needed some special motivation to use
a release not deemed stable.
> > 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.)
>
> And, I think there are issues if we go down the 'ad hoc' versioning system you
> are advocating. It'll be unclear when to upgrade your third-party apps.
> You'd be breaking apps built on SVN from one 'stable' release to another
> because some constituent library changed, but it was not viewed as a 'major'
> change.
>
> If I've learned anything from httpd, it's that a strong contract that is clear
> to everyone is essential. We screwed that up with httpd-2.0 at first, and
> only figured it out after we got nasty comments from people complaining about
> the moving target that was 2.0. I believe your versioning system is going to
> open Subversion up to the same criticisms. -- justin
It sounds like httpd 2.0 violated a different rule from the one you're
advocating:
Incompatible API and ABI changes are a big deal.
I am not suggesting we violate this rule. I am not suggesting we make
incompatible ABI changes without bumping the svn major version. I am
suggesting that ABI additions can be reflected independently between
libraries, and independent of the overall svn release number, without
raising any of the issues you fear.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 20 11:43:17 2003