You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/12/16 21:21:20 UTC
Things you must consider for version numbering
I'm seeing a lot of input on the version numbering thread which seems
to focus on one part of the development or release process without
considering all of it. So, let me draw a little picture:
-(A)--*---(D)-------------> trunk
\
(B)
\
(C)
\
(E) --> branch for next stable release
Assume 1.0 has recently been released at the beginning of this
picture. A complete post-1.0 version numbering proposal must answer
the following questions:
1) (A) is an unstable trunk release, or snapshot. If we have this
at all, what is it named?
2) (B) is a testing release leading to a new stable release. What
is it named?
3) (C) is the next stable release (ignoring bugfixes to 1.0). What
is it named?
4) (E) is a bugfix release to the next stable release. What is it
named?
5) (D) is an unstable trunk release, or snapshot, made after (C) but
before (E). If we have this at all, what is it named?
6) What does "svn --version" report for a private build of:
6.1) ... the trunk between A and *?
6.2) ... the release branch between * and B?
6.3) ... the release branch between B and C?
6.4) ... the release branch between C and D?
6.5) ... the trunk between * and the time of B?
6.6) ... the trunk between the time of B and the time of C?
6.7) ... the trunk between the time of C and (D)?
6.8) ... the trunk between (D) and the time of E?
6.9) ... the trunk after the time of E?
Here are my answers:
1) subversion-snapshot-rXXXXX
2) subversion-beta-1.1-rXXXXX
3) subversion-1.1.0
4) subversion-1.1.1
5) subversion-snapshot-rXXXXX
6.1) svn dev build, trunk rXXXXX
6.2) svn dev build, branch 1.1 rXXXXX
6.3) svn dev build, branch 1.1 rXXXXX
6.4) svn dev build, branch 1.1 rXXXXX
6.5) svn dev build, trunk rXXXXX
6.6) svn dev build, trunk rXXXXX
6.7) svn dev build, trunk rXXXXX
6.8) svn dev build, trunk rXXXXX
6.9) svn dev build, trunk rXXXXX
Here are Karl's answers, as best I understand them:
1) subversion-unstable-1.1.0
2) subversion-unstable-1.1.1
3) subversion-1.2.0
4) subversion-1.2.1
5) subversion-unstable-1.3.0
6) Not yet stated
(Prior practice is "svn, version X.Y.Z (dev build)" where X.Y.Z
is the most recent release we have branched for, even if we
haven't released it yet. What that means between C and D and E,
I am not sure.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 16, 2003 5:38 PM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> So, right now, if we put out 0.35.0, and it has a big bug, we put out
> 0.35.1. What happens in your scheme when we put out 1.1.2 and it has a
> big bug? Do we put out 1.1.2.1? Do we put out 1.1.3 even though 1.1.3
> would ordinarily come from a fresh branch?
Yes, I'd say it's 1.1.3. Under httpd versioning rules (which is essentially
what I'd like to see us follow), there would be no branches in the
'development' release models. It'd just be a tag (cp /trunk /tags/1.1.3). If
it doesn't work, who cares. Move on. There's no expectation of 'quality' or
'functionality' in a development release.
Only 'stable' would have a branch.
> I'm thinking, maybe we don't have to branch for unstable trunk
> releases. Just tar up the trunk at a particular revision, wait a few
> days or a week to make sure nobody finds any awful bugs applying to the
> time you tarred up the trunk, and release the tarball. If someone did
> discover an awful bug, try again as of the trunk revision the bug is
> fixed on.
Yes.
> The above discipline is not as robust as our practice for 0.x releases,
> nor is it as predictable. But it is less work and less complexity. And
> unlike today, people won't need to use interim releases for real work,
> and we won't be trying to put out interim releases every 2-3 weeks.
Right. Our 0.x releases are meant for mass consumption though, so we are
being very careful (rightfully so). However, once we have a 'stable' branch
out, we can feel free to issue dud 'unstable' releases.
For 'stable' releases, we should have branches and a refined testing policy,
but that's not what we want on /trunk for 'unstable' releases. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svnadmin errors on a win32 box
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
On Wed, 17 Dec 2003 01:46:43 +0100, "Arild Fines"
<ar...@broadpark.no> said:
> Craig Findlay wrote:
> > I am trying to do an svnadmin dump so I can upgrade from 0.33 to 0.34, and
> I
> > am getting the following errors:
> >
> > (Some other output snipped)
> > svn: Not enough storage is available to process this command.
> > svn: write_handler_apr: error writing file
> >
> > Can anyone enlighten me on this? The repository is on a Windows XP Pro
> > machine, and svn 0.33.1 is installed.
> >
I saw that too when I dumped my own repos. I executed the following:
\svn33\svnadmin dump repos | \svn34\svnadmin load repos34
> > Also on a related topic, if I can get the dump to work, where does the
> dump
> > file get written?
>
> Normally it goes to standard out, which makes your error message a little
> weird. What was the exact command you used?
>
[snip]
It looks like on Windows, a temporary file is written to disk when piping
output from one command to another. When I gave myself some more elbow
room, the dump proceeded nicely. It took about one hour to dump/load
~1600 revisions.
Bye !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin errors on a win32 box
Posted by Craig Findlay <cr...@plasmatronics.com.au>.
You're right! Sorry for the waste of bandwidth. Next time I will put my
brain into gear first and read the documentation!
Cheers,
Craig
----- Original Message -----
From: "Arild Fines" <ar...@broadpark.no>
To: "Craig Findlay" <cr...@plasmatronics.com.au>;
<de...@subversion.tigris.org>
Sent: Wednesday, December 17, 2003 11:46 AM
Subject: RE: svnadmin errors on a win32 box
> Craig Findlay wrote:
> > I am trying to do an svnadmin dump so I can upgrade from 0.33 to 0.34,
and
> I
> > am getting the following errors:
> >
> > (Some other output snipped)
> > svn: Not enough storage is available to process this command.
> > svn: write_handler_apr: error writing file
> >
> > Can anyone enlighten me on this? The repository is on a Windows XP Pro
> > machine, and svn 0.33.1 is installed.
> >
> > Also on a related topic, if I can get the dump to work, where does the
> dump
> > file get written?
>
> Normally it goes to standard out, which makes your error message a little
> weird. What was the exact command you used?
>
>
> --
> Arild
>
> AnkhSVN: http://ankhsvn.tigris.org
> Blog: http://ankhsvn.com/blog
> RSS: http://ankhsvn.com/blog/Rss.aspx
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svnadmin errors on a win32 box
Posted by Arild Fines <ar...@broadpark.no>.
Craig Findlay wrote:
> I am trying to do an svnadmin dump so I can upgrade from 0.33 to 0.34, and
I
> am getting the following errors:
>
> (Some other output snipped)
> svn: Not enough storage is available to process this command.
> svn: write_handler_apr: error writing file
>
> Can anyone enlighten me on this? The repository is on a Windows XP Pro
> machine, and svn 0.33.1 is installed.
>
> Also on a related topic, if I can get the dump to work, where does the
dump
> file get written?
Normally it goes to standard out, which makes your error message a little
weird. What was the exact command you used?
--
Arild
AnkhSVN: http://ankhsvn.tigris.org
Blog: http://ankhsvn.com/blog
RSS: http://ankhsvn.com/blog/Rss.aspx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svnadmin errors on a win32 box
Posted by Craig Findlay <cr...@plasmatronics.com.au>.
I am trying to do an svnadmin dump so I can upgrade from 0.33 to 0.34, and I
am getting the following errors:
(Some other output snipped)
svn: Not enough storage is available to process this command.
svn: write_handler_apr: error writing file
Can anyone enlighten me on this? The repository is on a Windows XP Pro
machine, and svn 0.33.1 is installed.
Also on a related topic, if I can get the dump to work, where does the dump
file get written?
Cheers,
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 16:34, kfogel@collab.net wrote:
> (An "unstable trunk release, or snapshot" still involves a branch, of
> course, just a very short-lived one. Such releases are analogous to
> the interim releases we do right now -- 0.35, etc -- which can be
> considered snapshots from the 0.x line.)
So, right now, if we put out 0.35.0, and it has a big bug, we put out
0.35.1. What happens in your scheme when we put out 1.1.2 and it has a
big bug? Do we put out 1.1.2.1? Do we put out 1.1.3 even though 1.1.3
would ordinarily come from a fresh branch?
I'm thinking, maybe we don't have to branch for unstable trunk
releases. Just tar up the trunk at a particular revision, wait a few
days or a week to make sure nobody finds any awful bugs applying to the
time you tarred up the trunk, and release the tarball. If someone did
discover an awful bug, try again as of the trunk revision the bug is
fixed on.
The above discipline is not as robust as our practice for 0.x releases,
nor is it as predictable. But it is less work and less complexity. And
unlike today, people won't need to use interim releases for real work,
and we won't be trying to put out interim releases every 2-3 weeks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Here are Karl's answers, as best I understand them:
>
> 1) subversion-unstable-1.1.0
> 2) subversion-unstable-1.1.1
> 3) subversion-1.2.0
> 4) subversion-1.2.1
> 5) subversion-unstable-1.3.0
Yeah, that looks right.
(An "unstable trunk release, or snapshot" still involves a branch, of
course, just a very short-lived one. Such releases are analogous to
the interim releases we do right now -- 0.35, etc -- which can be
considered snapshots from the 0.x line.)
> 6) Not yet stated
> (Prior practice is "svn, version X.Y.Z (dev build)" where X.Y.Z
> is the most recent release we have branched for, even if we
> haven't released it yet. What that means between C and D and E,
> I am not sure.)
I'm fine using a revision number to express that this is "version
X.Y.Z, plus some changes", e.g.:
svn, version X.Y.Z.rRRRR
although I think we tried this once and discovered that, even with the
assistance of 'svnversion', it was still not easy to implement
reliably. However, if that can be solved (maybe we look at the top
level README in the tree or something?), then using a revision number
is fine. Otherwise, "(dev build)" is a nice, simple solution.
To use a revision numbr, the formula is simply to take the most recent
version name in the ancestry leading up to the dev build, and tack on
the revision. Thus:
6.1) ... the trunk between A and *?
subversion-unstable-1.1.0.rRRRR
6.2) ... the release branch between * and B?
subversion-unstable-1.1.0.rRRRR [but see below]
6.3) ... the release branch between B and C?
subversion-unstable-1.1.1.rRRRR
6.4) ... the release branch between C and D?
subversion-1.2.0.rRRRR
6.5) ... the trunk between * and the time of B?
subversion-unstable-1.1.0.rRRRR
6.6) ... the trunk between time of B and time of C?
subversion-unstable-1.1.0.rRRRR
6.7) ... the trunk between the time of C and (D)?
subversion-unstable-1.1.0.rRRRR
6.8) ... the trunk between (D) and the time of E?
subversion-unstable-1.3.0.rRRRR
6.9) ... the trunk after the time of E?
subversion-unstable-1.3.0.rRRRR
(Of course, "RRRR" isn't the same every time!)
Note that in 6.2, the name doesn't indicate that it's from the release
branch, because the patch number hasn't yet been incremented on that
branch -- that won't happen until (B).
If this is a huge problem, one way to fix it is to increment the patch
number right away when we branch. That way there's no chance of a dev
build not including the new patch number. There is already a
precedent for such early bumping (it's Step 2 in notes/releases.txt).
But then we'd have to bump the patch number again right before
releasing (B).
I'm not sure it's worth it to look for a workaround here. A dev build
is inherently ill-defined, since it might be only partially updated to
the revision anyway. Having some release number, plus a revision, is
enough to tell us approximately what incarnation of Subversion the
user is running -- if we still can't determine whether they have a
particular fix, we can ask them to run 'svn log' on a file. Bug
reports from dev builds are pretty rare; reports from dev builds where
the person is not an experienced svn developer are even rarer. We
shouldn't let dev builds influence our numbering scheme very much.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 12:15 PM -0600 kfogel@collab.net wrote:
> I didn't see a personal attack there. Greg is trying to make a simple
> statement of fact, with no implication of personal failure on your
> part. Rather the opposite, since he's crediting you with
Let me just say 'mea culpa.' I completely misread Greg's tone in his message.
My apologies to Greg and everyone else for the confusion. Sorry. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > 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.
I didn't see a personal attack there. Greg is trying to make a simple
statement of fact, with no implication of personal failure on your
part. Rather the opposite, since he's crediting you with
understanding the issues, but saying you simply haven't had time to
make a complete proposal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: Things you must consider for version numbering
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 7:52 PM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> 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.
If we are really making incompatible changes to our command-line client, why
would we only be bumping the patch level? That seems wrong to be advocating
from the users' perspective. (I've been asking how do the non-API things
trigger a version bump. I think some of them do - such as schema changes,
incompatible protocol changes, etc. No one seems interested in that yet.)
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. Mozilla (and Linux and FreeBSD to some extent)
side-step compatibility as they don't really have binary compatibility.
Mozilla just uses the old Netscape plugin API which, AIUI, doesn't change
because doing so would be harmful to their installed base.
I think the largest benefit of Subversion over CVS will be its extensibility.
I think we're in agreement about that, but I also want it to be clear how to
manage changes in the 'core' distribution released from tigris.org. I'm just
not sure that we can splice apart the versioning into things that we aren't
decomposing ourselves.
Let me explain with an analogy:
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. Keith's perspective is
that it'll stabilize over time, so the initial anarchy and confusion caused by
the split will eventually stabilize and produce something useful.
We did discuss in depth over in httpd-land about switching to that model. It
wasn't really positively received because of the differences between X and
httpd. I think some of the same rationale applies here in Subversion.
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.
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.
Now, remember that Keith's goal was purposely to create fiefdoms as that's
certainly better than what X has now. Keith also admitted that it comes at a
price: inter-operability between the libraries is going to be a *big* problem.
How do you make sweeping changes if there are 20 different releases that
constitute X? You could have a flag day and try to convince all of the
fiefdoms to change; but there's human scalability problems there. I think
that that the Subversion developers would want a unified vision of how the
libraries should operate that is consistent across libraries.
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?
If you want to go the route of only relying upon an individual library's
version, then I think we must go Keith's route and split the release up - make
every library stand on its own and released on its own. Packaging things up
as a collection and saying, "Oh, the *real* version information is hidden
inside of this meta-version; you must look at these twenty different libraries
to figure out if you're third-party app is compatible" strikes me as we can do
better than that.
> * 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.
If we stick to the versioning API advocated by APR, perhaps. If it's that
critical, I think we could find a way to create a release that didn't require
a minor bump. Don't export the new function, or whatever. *shrug* We've
done that in httpd.
Yet, our deltas from 1.0->1.1/1.2 could be 'minor' and frequent. Note that's
also what we're doing right now: 0.34->0.35. That's goodness, and something I
think httpd hasn't figured out how to do yet - what's the 'right' size of
change between minor versions? I'd prefer Subversion to produce new 'minor'
versions every few months. Don't bother backporting to the previous minor
version, but rely upon solid versioning rules to manage expectations as we
produce new minor releases that add functionality.
I think a huge disparity in this conversation is how often we expect to
produce releases and of what type. Are we going to produce 1.0 and then
immediately do 1.0.1, 1.0.2, 1.0.3 every two weeks. And, in six months, will
we produce 1.1 (or 1.2 if we follow even/odd)? Or, is the time between 1.0
and 1.1 much shorter?
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.
> * 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 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?
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. 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? Both times, we decided to punt and deal with it when we
had to. (At one point, we said that 0 should be considered odd; which isn't
unreasonable but isn't very user-friendly, I think. Arrays start at 1 was a
good argument for why it'd pass muster!)
> * 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).
Again, unstable releases (or anything derived from trunk) would not have
binary compatibility rules in place relative to each other, but they *should*
work against the previous stable version per binary compatibility rules.
Remember my key constraint is that private builds have *some* x.y.z version
number attached. If y denotes it is 'unstable', then it means that it should
be binary compatible to y-1 and should be the progress towards the y+1 API.
> 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.
I don't understand.
> 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.).
> * 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-12-19 at 13:38, Justin Erenkrantz wrote:
> --On Friday, December 19, 2003 12:17 PM -0500 Greg Hudson <gh...@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
Re: Things you must consider for version numbering
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 12:17 PM -0500 Greg Hudson <gh...@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.
I think your proposal does not provide a guide to third-party developers as to
what has changed from one SVN release to another. Therefore, I think our
versioning rules must apply to the *entire* SVN tree not a particular library.
I don't think that placing the versioning only at the library level is going
to work. It'll be too confusing for applications to have to say, "Subversion
1.1 has libsvn_wc 2.5, libsvn_repos 9.6, libsvn_ra 3.9." I've yet to be
convinced that your proposal is helpful to any third-parties or users. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-12-19 at 11:09, kfogel@collab.net wrote:
> Yes, I know. Oy vey :-). Everybody agrees on this. Unblessed builds
> should have version numbers. I think so, John thinks so too, Greg
> Hudson thinks so, Kofi Annan thinks so. And all the proposals offered
> meet this criterion, if I recall correctly. Nobody said unblessed
> releases shouldn't have versioning; that's not what my response above
> is saying either.
No, it's not that simple. Justin says that unblessed builds need
release numbers which live in the same version space as blessed release
numbers, so that you know what releases an unblessed build is compatible
with.
My proposal does not have this property, since unblessed releases (and
snapshots and beta builds) are tagged by revision.
Your proposal does not really have this property either. We'd have to
bump the minor version by two each time we added a new function to the
library in order to get the desired property. (Have a careful look at
http://apr.apache.org/versioning.html where it describes "Patch Version"
vs. "Minor Versions".) Or at the very least, each time we released a
trunk snapshot containing new functions. Really, I don't see how
Justin's constraints are compatible with any common version-numbering
system. (You might think Apache uses it, but since as far as I know no
APR project has reached 1.0 yet, they actually have no field experience
with it as far as I know. Also, APR projects have separate projects for
each library, while we do not, which changes the constraints
significantly.)
> > Since there is server/client-compatibility/repository schemas encoded
> > into a version, I think it's critical that everything have a readable
> > version no matter if it is blessed or not. Otherwise, the user has no
> > clue what 'blessed releases' it is compatible with. For example, in
> > the short term, we expect trunk should be 1.0 compatible; long term,
> > we have no idea what 2.0 will mean to users. -- justin
>
> Yes. You may stop fighting this battle. You won. In fact, we were
> all on the same side, and there was no opposition :-).
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.)
See http://www.contactor.se/~dast/svn/archive-2003-12/0290.shtml for an
example of opposition.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > Yes, I understand. But Greg's questions 1-5 were not about this kind
> > of build, that's all I'm saying. They were about blessed releases.
> > It's fine to discuss other kinds of builds, but it's confusing to
> > offer them as answers to questions about blessed releases :-).
>
> Well, I think 'unblessed' releases (i.e. from trunk by Joe Random
> developer aka Justin) needs some type of versioning information, too -
> just to provide a point of reference. *I* need version information,
> too.
Yes, I know. Oy vey :-). Everybody agrees on this. Unblessed builds
should have version numbers. I think so, John thinks so too, Greg
Hudson thinks so, Kofi Annan thinks so. And all the proposals offered
meet this criterion, if I recall correctly. Nobody said unblessed
releases shouldn't have versioning; that's not what my response above
is saying either.
> Since there is server/client-compatibility/repository schemas encoded
> into a version, I think it's critical that everything have a readable
> version no matter if it is blessed or not. Otherwise, the user has no
> clue what 'blessed releases' it is compatible with. For example, in
> the short term, we expect trunk should be 1.0 compatible; long term,
> we have no idea what 2.0 will mean to users. -- justin
Yes. You may stop fighting this battle. You won. In fact, we were
all on the same side, and there was no opposition :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, December 17, 2003 2:10 PM -0600 kfogel@collab.net wrote:
> Yes, I understand. But Greg's questions 1-5 were not about this kind
> of build, that's all I'm saying. They were about blessed releases.
> It's fine to discuss other kinds of builds, but it's confusing to
> offer them as answers to questions about blessed releases :-).
Well, I think 'unblessed' releases (i.e. from trunk by Joe Random developer
aka Justin) needs some type of versioning information, too - just to provide a
point of reference. *I* need version information, too.
Since there is server/client-compatibility/repository schemas encoded into a
version, I think it's critical that everything have a readable version no
matter if it is blessed or not. Otherwise, the user has no clue what 'blessed
releases' it is compatible with. For example, in the short term, we expect
trunk should be 1.0 compatible; long term, we have no idea what 2.0 will mean
to users. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> $ svn --version
> svn, version 0.35.0 (dev build)
>
> I built this two days ago, from this path:
>
> URL: http://svn.collab.net/repos/svn/trunk
>
> so obviously sometimes someone may build something other than from one
> of the blessed releases. Shouldn't we make that part of our
> discussion too? All I'm saying is that I would prefer that this would
> report the revision, too, instead of the generic "(dev build)" tag.
> The presence of the string "0.35.0" is useful to humans, more so that
> just "r8000" would be...
Yes, I understand. But Greg's questions 1-5 were not about this kind
of build, that's all I'm saying. They were about blessed releases.
It's fine to discuss other kinds of builds, but it's confusing to
offer them as answers to questions about blessed releases :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> We're talking about blessed releases in these questions -- releases
> that came from us, via the release manager. Those are never "dev
> builds", and there's no reason for them to include a revision number.
The discussion should be both "what do we call the tar files" as well as "what
does subversion print out from the command line."
$ svn --version
svn, version 0.35.0 (dev build)
I built this two days ago, from this path:
URL: http://svn.collab.net/repos/svn/trunk
so obviously sometimes someone may build something other than from one of the
blessed releases. Shouldn't we make that part of our discussion too? All I'm
saying is that I would prefer that this would report the revision, too, instead
of the generic "(dev build)" tag. The presence of the string "0.35.0" is useful
to humans, more so that just "r8000" would be...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> > Here are Karl's answers, as best I understand them:
> > 1) subversion-unstable-1.1.0
> > 2) subversion-unstable-1.1.1
> > 3) subversion-1.2.0
> > 4) subversion-1.2.1
> > 5) subversion-unstable-1.3.0
>
> And my suggestions would be the following (more like a combination of the two):
>
> 1) subversion-unstable-1.1.0-rXXXX
> 2) subversion-unstable-1.1.1-rXXXX
> 3) subversion-1.2.0
> 4) subversion-1.2.1
> 5) subversion-unstable-1.3.0-rXXXX
>
> because e.g. #1 could be built from multiple revs, depending on when
> during that week or two that I ran 'svn up' before building.
Hrm?
We're talking about blessed releases in these questions -- releases
that came from us, via the release manager. Those are never "dev
builds", and there's no reason for them to include a revision number.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Things you must consider for version numbering
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Here are Karl's answers, as best I understand them:
>
> 1) subversion-unstable-1.1.0
> 2) subversion-unstable-1.1.1
> 3) subversion-1.2.0
> 4) subversion-1.2.1
> 5) subversion-unstable-1.3.0
And my suggestions would be the following (more like a combination of the two):
1) subversion-unstable-1.1.0-rXXXX
2) subversion-unstable-1.1.1-rXXXX
3) subversion-1.2.0
4) subversion-1.2.1
5) subversion-unstable-1.3.0-rXXXX
because e.g. #1 could be built from multiple revs, depending on when during that
week or two that I ran 'svn up' before building. Remember, someone might use a
version other then one that was packaged (whether we are talking about tar files
or zipped Windows installers). By appending the revision number to any
non-stable release, we can immediately say "Ah, you are building against TRUNK,
not one of our snapshots!"
The only other alternative I would offer is this:
2b) subversion-1.2.0-RC1
since that more closely replicates what (B) corresponds to. I even have one way
of doing that without too much pain (attached).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747