[ changing subject; this isn't about a schedule any more ]
On Fri, Dec 05, 2003 at 12:34:23PM -0500, Greg Hudson wrote:
> On Fri, 2003-12-05 at 04:14, Greg Stein wrote:
> > People are going to want to try the new features, and we are going to
> > *want* them to try them out. This is going to be necessary *before* we
> > create a 1.1 branch. Thus, I believe your assumptions above will not work
> > out for us very well.
>
> First, I don't agree. Very few projects need these kind of interim
> releases. One very visible project (Linux) does, but if you look
> broadly at open source projects, they generally don't.
I tend to disagree because I think some people are quite willing to take
the intermediate/unstable/testing snapshots as a way to get features
sooner rather than later. i.e. they're willing to trade stability for
features. That's from the user side; your point is whether the producer
side helps them out :-)
But in this matter, I think we're probably quite fine with agreeing to
disagree -- it is kind of a side point.
> Second, if you turn out to be right and we do want to do this, then I
> think we can release "svn-snapshot-r8859.tar.gz". Other projects do
> this from time to time. Binary packagers can either avoid packaging the
> snapshots, or make svn-snapshot packages which conflict with svn
> packages.
I'm cool with this approach. We used the rev number in our releases for a
while. We punted on that and switched to version numbers because that was
more useful for users (revnum is good for us).
I'll go one further than you, and say that we don't worry about the binary
packagers at all. If they want to munge a snapshot into a "release", then
they can. But they aren't going to have a valid version number, so it will
be quite difficult for them to produce a stream.
That said: creating RPMs or dpkgs or whatever for the developers shouldn't
be totally untenable, but I think we can certainly allow for some pain.
For example, we might recommend that snapshots are always installed into
/usr/local/svn-snapshot/, and that the users (developers, in this case)
just need to properly update their various paths to point into that area.
> > I also prefer consistent triplets(*), and along that line, I dislike the
> > 1.1.betaN format. The even/odd works well because we can do 1.1.0 thru
> > 1.1.20, and then pop it to 1.2.0 for the stable release.
>
> Well, then we have a decision to make. We cannot reconcile "completely
> numeric versions" with "unstable versions must be explicitly marked as
> such." No compromise will satisfy both constraints. And I think once
> we've made a decision, there's no benefit in "compromising"
> (particularly since any compromise would violate the first constraint).
I believe the svn-snapshot-rNNNN mechanism neatly sidesteps the need for
this decision. Since we won't apply version numbers to intermediate
(unstable) releases, then we don't need even/odd as a marker. We also
don't need "beta" or whatnot in the name.
> Incidentally, I'll note that Linux does not use pure numeric versions;
> they go with odd middle numbers for unstable development but then when
> they want to transition to a new even release, they come out with
> versions like "2.6.0-test11" or "2.2.0-pre3" for a while.
Sure, but I'll note that I don't like that either :-) Pure numbers for
me... :-)
> In another message, Colin Watson said of my proposed scheme:
> > It's not compatible with dpkg, though:
No problem. I think we can avoid this. If we want unstable packages, then
we can call them svn-snapshot-0.NNNN or somesuch. Dunno. Another
possibility would be 1.1.0.NNNN, if that will end up sorting lower than
1.1.0. (or our first stable release could be 1.1.1).
>...
> A modification of the Berkeley DB scheme satisfies my constraints while
> still guaranteeing correct sorting:
>
> 1.1.0-alpha
> 1.1.1-alpha
> 1.1.2-beta
> 1.1.3-beta
> 1.1.4
>
> This is similar to Fitz's compromise except that instead of even-odd, we
> release at 1.1.n (n>0) instead of bumping to an even middle version
> number. I think I still prefer my previous proposal, dpkg issues
> notwithstanding, but I'm willing to budge.
Yah, tho I'd go with the snapshot proposal. To support interim packagers,
we could say that our initial stable release will be 1.1.1 so that they
can use 1.1.0.NNNN for those interim builds.
But I would hope that the packages will take great care to either *not*
package the stuff, or to label them as unstable / derived from the
snapshots. To some extent, we can name our tarballs whatever, and the
packages could still "get around" us, so it may make sense to at least
provide a plan for them. (despite my preference that packages are not
created from the interim snapshot releases)
Summarizing my email... it is just what Kevin posted:
* interim releases are revnum-labeled
* stable releases are version-labeled
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 22:55:58 2003