You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/12/04 04:10:08 UTC
0.35 => Beta => 1.0 schedule
Our last planned interim milestone in Alpha is 0.35, which is
scheduled to be code-complete on Friday, 12 Dec. (There are two
issues remaining, one of which -- #1601 -- is still under discussion,
but we should be able to get it wrapped up by the 12th.) The 0.35
branch will sit for the usual one week soak, then we'll tag it and the
tarball will come out on 19th December.
At that point, I think we're ready to enter Beta. Here's a plan,
comments welcome of course.
First, create a Beta line off the 0.35.0 tag:
$ svn cp -m "Create branch for Beta / 1.0 stabilization." \
http://svn.collab.net/repos/svn/tags/0.35.0
http://svn.collab.net/repos/svn/branches/1.0-stabilization
Note that the word "Beta" does not appear in the branch name, just as
the word "Alpha" doesn't appear in our current interim release names.
Beta is a state of mind that may apply to various interim releases,
and its goal is to reach 1.0. We don't want to spend a long time in
Beta, just long enough to shake out important bugs.
Hence the name of the branch, "1.0-stabilization". The point of this
branch is to terminate in a 1.0 release. Trunk development will
continue in parallel with the 1.0-stabilization branch, but many trunk
changes will *not* be ported over to the branch. Exactly which
changes get merged and which don't will be decided by the release
manager (Jostein), in consultation with the developers, but the
general goal is to avoid destabilizing the branch. We've always known
there would be open issues when we ship, that's just the way it is on
an active project. We need to avoid the temptation to close all of
those issues for 1.0 :-).
During the Beta period, we will put out interim releases (0.36, 0.37,
and so on) from the 1.0-stabilization branch as necessary. I think we
should not bother with releases from the trunk during that time.
After 1.0 comes out, we can start putting out development releases
from trunk again, named "subversion-1.1.X.tar.gz", with X increasing
each time. Simultaneously, we should maintain the stable 1.0 line for
critical bugfixes, with (less frequent) releases, named
"subversion-1.0.X.tar.gz", with X increasing. No new features would
ever be introduced in the 1.0.X line, of course.
This is essentially the "even==stable, odd==dev" scheme that many
other projects use. I've already renamed the "1.1" milestone to "1.2"
in anticipation of this, so that we can release 1.1.X tarballs and
have it be understood that a) they're leading to 1.2.0, and b) any fix
present in a 1.0.X release is also present in all 1.1.X releases,
either by implication, obviation, or direct merging. We'll document
all this clearly on the web site, of course.
It's not my intention here to start a thread about where the 1.1.X
line is going (i.e., about the definition of 1.2). That's a separate
conversation, which we can have later. This is just about 1.0.
Naturally we can't be certain how long the 1.0-stabilization branch
will last, but I'm hoping not more than a month or two -- in other
words, a 1.0 release sometime in the first few months of 2004. The
exact date will depend on what we discover in testing.
Questions? Comments? Fresh vegetables?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> I better get those changes for my issue 897 checked in fast! :-)
>
> [ snip the part which explains the process; I agree ]
In general, that's a very dangerous attitude :-). We don't want
people thinking "Oh, a release is coming up, better squeeze all my
changes in before it goes out!" unless they have issues specifically
planned to be completed for that release. It's much better not to
have stuff rushed in like that.
As issue #897 is about making error messages clearer and more
consistent, this particular issue is not very dangerous, so you can do
as much of it as you want before 1.0. Just note that the release will
not be held up for this issue.
> > Exactly which
> > changes get merged and which don't will be decided by the release
> > manager (Jostein), in consultation with the developers, but the
> > general goal is to avoid destabilizing the branch.
>
> This (potentially) puts a lot more work on the hands of the release manager.
> Maybe we should consult Jostein if he has this amount of time available
> after we agree that this is how it is going to work.
>
> [ snip the open issues part ]
I don't think it's that much more work, because realistically, he'll
have to delegate a lot of that decision-making to the full committers.
And he can make some of that delegation explicit, e.g., he can say
"Ben is allowed to merge changes to the 1.0-stabilization branch
according to his judgement", so that Jostein doesn't have to do
everything.
IOW, if it's too much work, Jostein can find additional workers.
> And here you did not say that there will be no releases for 1.0 while
> releasing from the trunk. Did you?
The purpose of a maintenance line is to release bugfixed versions of
the stable software, without including new features. So after 1.0
comes out, then yes, there would be releases from both lines, though
the 1.0.X releases would be much less frequent than the 1.1.X
releases, because they'd only be done as needed.
> I think this is very clear. One question though: From the 1.0.X and 1.1.X
> part I conclude that we will be releasing fixes for 1.0 and fixes
> and features for 1.1 in equal pace? i.e the X in 1.0.X was
> intentionally the same X as the one in 1.1.X?
Actually, no. The development line (1.1.X) releases much more frequently.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Erik Huelsmann <e....@gmx.net>.
> Our last planned interim milestone in Alpha is 0.35, which is
> scheduled to be code-complete on Friday, 12 Dec. (There are two
> issues remaining, one of which -- #1601 -- is still under discussion,
> but we should be able to get it wrapped up by the 12th.) The 0.35
> branch will sit for the usual one week soak, then we'll tag it and the
> tarball will come out on 19th December.
>
> At that point, I think we're ready to enter Beta. Here's a plan,
> comments welcome of course.
I better get those changes for my issue 897 checked in fast! :-)
[ snip the part which explains the process; I agree ]
> Hence the name of the branch, "1.0-stabilization". The point of this
> branch is to terminate in a 1.0 release. Trunk development will
> continue in parallel with the 1.0-stabilization branch,
Good.
> but many trunk
> changes will *not* be ported over to the branch.
Very well.
> Exactly which
> changes get merged and which don't will be decided by the release
> manager (Jostein), in consultation with the developers, but the
> general goal is to avoid destabilizing the branch.
This (potentially) puts a lot more work on the hands of the release manager.
Maybe we should consult Jostein if he has this amount of time available
after we agree that this is how it is going to work.
[ snip the open issues part ]
And now onto the most user-visible part of it all ...
> During the Beta period, we will put out interim releases (0.36, 0.37,
> and so on) from the 1.0-stabilization branch as necessary. I think we
> should not bother with releases from the trunk during that time.
I agree that *during stabilization* we should not release from the trunk.
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
Julian Foad <ju...@btopenworld.com> writes:
> Do issues that are not in the issue tracker count? I'm thinking of
> the inconsistent handling of property value encodings.
IMHO, anything that goes into the 1.0 line needs an issue filed. If
we don't abide by that discipline, then we'll never have a clear sense
of how much work is left at any given point.
(I personally haven't felt that the property value encoding thing
needs to be solved for 1.0, that's why I haven't been responding in
the thread nor filing an issue for it. If a lot of people feel
differently, though, then... Well, let's talk :-) ).
> As these interim releases are intended to be for important bug fixes
> only, should these not be numbered 0.35.1, 0.35.2, etc. to be
> consistent with both our current and future numbering schemes? For
> example, the 1.1 series will go 1.1.1, 1.1.2 etc. (rather than 1.2,
> 1.3, etc.) while it stabilises for a 1.2 release.
Good point, thanks! Yes, let's do it that way.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Andy Whitcroft wrote:
>> As these interim releases are intended to be for important bug fixes
>> only, should these not be numbered 0.35.1, 0.35.2, etc. to be consistent
>> with both our current and future numbering schemes? For example, the 1.1
>> series will go 1.1.1, 1.1.2 etc. (rather than 1.2, 1.3, etc.) while it
>> stabilises for a 1.2 release.
>
>
> Hmmm, well whatever is fine. But I don't think you should stop dropping
> and shipping trunk based tarballs for people to test. I don't see any
> problem releasing 1.1.1 etc even if 1.0.1 has yet to leave the dock?
I disagree. Rolling a release takes a non-trivial amount of time and
effort, and expecting people to create, test, and release tarballs from
multiple branches at a time seems like a bit much at this point. Anyone
who wants to test the trunk version is free to check it out, and any
'safe' bug fixes will likely be merged into the branch anyway.
Also, I'd much rather have our users testing what will become version
1.0, so we can find problems there, than have them testing the
development version.
So yeah, at this point I'd vote to hold off on releases from the trunk
while we're trying to stabalize 1.0 on the branch.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Andy Whitcroft <ap...@shadowen.org>.
--On 04 December 2003 12:45 +0000 Julian Foad <ju...@btopenworld.com>
wrote:
>> Our last planned interim milestone in Alpha is 0.35, which is
> [...]
>> During the Beta period, we will put out interim releases (0.36, 0.37,
>> and so on) from the 1.0-stabilization branch as necessary. I think we
>
> As these interim releases are intended to be for important bug fixes
> only, should these not be numbered 0.35.1, 0.35.2, etc. to be consistent
> with both our current and future numbering schemes? For example, the 1.1
> series will go 1.1.1, 1.1.2 etc. (rather than 1.2, 1.3, etc.) while it
> stabilises for a 1.2 release.
Hmmm, well whatever is fine. But I don't think you should stop dropping
and shipping trunk based tarballs for people to test. I don't see any
problem releasing 1.1.1 etc even if 1.0.1 has yet to leave the dock?
Cheers.
-apw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Julian Foad <ju...@btopenworld.com>.
kfogel@collab.net wrote:
> Our last planned interim milestone in Alpha is 0.35, which is
> scheduled to be code-complete on Friday, 12 Dec. (There are two
> issues remaining, one of which -- #1601 -- is still under discussion,
> but we should be able to get it wrapped up by the 12th.) The 0.35
Do issues that are not in the issue tracker count? I'm thinking of the inconsistent handling of property value encodings.
> Our last planned interim milestone in Alpha is 0.35, which is
[...]
> During the Beta period, we will put out interim releases (0.36, 0.37,
> and so on) from the 1.0-stabilization branch as necessary. I think we
As these interim releases are intended to be for important bug fixes only, should these not be numbered 0.35.1, 0.35.2, etc. to be consistent with both our current and future numbering schemes? For example, the 1.1 series will go 1.1.1, 1.1.2 etc. (rather than 1.2, 1.3, etc.) while it stabilises for a 1.2 release.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Erik Huelsmann <e....@gmx.net>.
> > and they made the point that it's a lot easier to set termination
> > conditions for a branch. The branch gives the release manager more
> > freedom to make stabilization decisions. For example, there have been
> > a whole lot of medium-impact commits in the last few weeks on trunk.
> > If this trend continues, we would face a choice between discouraging
> > people from doing that work, or having lots of code churn just when
> > we're trying to stabilize for release.
>
> This kind of reasoning works when you're looking at stabilizing a
> release for 2-6 weeks. When you're stabilizing for six months, you
> really have to do that on the trunk. I've seen this go bad; too many
> developers stick with the trunk and the release doesn't get enough
> attention, or (less likely) too many developers stick with the release
> branch and the trunk festers with changes whose brokenness isn't
> exposed.
In which case you are actually pointing out that this greatly depends on the
time frame we have in mind. Is there anybody who thinks we can stabilize
within 6 weeks?
bye.
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 04, 2003 at 03:22:30PM -0500, John Peacock wrote:
> Greg Hudson wrote:
> > Users are presented with version numbers in a vacuum all the time. They
> > run into an already-installed version, they visit an FTP site, they do
> > an rpmfind query, whatever. We don't control the user's first encounter
> > with Subversion.
>
> And in each of those cases, there is some context. Anyone packaging an RPM
> would be foolish not to note "Stable" vs "Development" release, etc. It is not
> uncommon that the development releases are only available in user-unfriendly
> form (checked out from the repository vs. RPM). As long as it is clear on the
> official site what the Stable release is, it doesn't matter what to call the files.
Agreed. Either the filename uses the even/odd methodology, or you must
actually include the *word* stable/unstable into the name. One or the
other is needed to specify stability. I don't think we want any words in
the version number / filename, so that leaves the version number.
> All I am saying is that the 'even/odd' distinction is mostly for the developers
> sanity, and is in use today in a wide variety of settings and works well (c.f.
> Linux kernel). I don't see a lot of reason to get worked up over it, nor is
> there a better scheme available.
Agreed.
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
Re: 0.35 => Beta => 1.0 schedule
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Users are presented with version numbers in a vacuum all the time. They
> run into an already-installed version, they visit an FTP site, they do
> an rpmfind query, whatever. We don't control the user's first encounter
> with Subversion.
And in each of those cases, there is some context. Anyone packaging an RPM
would be foolish not to note "Stable" vs "Development" release, etc. It is not
uncommon that the development releases are only available in user-unfriendly
form (checked out from the repository vs. RPM). As long as it is clear on the
official site what the Stable release is, it doesn't matter what to call the files.
All I am saying is that the 'even/odd' distinction is mostly for the developers
sanity, and is in use today in a wide variety of settings and works well (c.f.
Linux kernel). I don't see a lot of reason to get worked up over it, nor is
there a better scheme available.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 14:55, John Peacock wrote:
> Greg Hudson wrote:
>
> > Nothing's going to be perfect, but I don't consider it acceptable to
> > have a version number like "1.1.6" and the user is just supposed to know
> > that that's not a real, stable release because the middle number is odd.
>
> Except that the user is never presented with "1.1.6" in a vacuum.
Users are presented with version numbers in a vacuum all the time. They
run into an already-installed version, they visit an FTP site, they do
an rpmfind query, whatever. We don't control the user's first encounter
with Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Nothing's going to be perfect, but I don't consider it acceptable to
> have a version number like "1.1.6" and the user is just supposed to know
> that that's not a real, stable release because the middle number is odd.
Except that the user is never presented with "1.1.6" in a vacuum. If the web
site clearly states that "1.0.4" is the current stable release and "1.1.6" is
the current developer release, that isn't going to be confusing at all. Even
better is if the web site has two tracks, so that "Downloads" leads to only the
stable releases and "Developers" leads to a page with the dev releases.
Speaking from personal experience (certainly with Perl), the notion that
even==stable and odd==dev is rarely discussed except in the footnotes. Good UI
design on the web site means that the stable release is obvious (regardless of
it's version number) and that only people interested in the development releases
will bother to look around for them.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 04 December 2003 20:26, Jani Averbach wrote:
> On 2003-12-04 18:08-0600, kfogel@collab.net wrote:
> > Regarding that other topic, numbering schemes:
>
> ...
>
> First of, I am happy with even/odd scheme - users have to always find
> out what is the stable version and what is the development version (if
> there is any). If you just start poking around ftp server, and grab
> what ever you first find, you are digging blood from your
> nose. Moreover, what ever the schema will be, it should be documented
> very top of README/INSTALL so I really don't see an issue here.
>
> However, may I introduce my own proposal? =)
>
> > Thus we'd have a stable maintenance line like this
> >
> > subversion-1.0.0.tar.gz
> > subversion-1.0.1.tar.gz
> > subversion-1.0.2.tar.gz
> >
> > And development releases like this:
> >
> > subversion-1.1.0-dev.tar.gz
> > subversion-1.1.1-dev.tar.gz
> > subversion-1.1.2-dev.tar.gz
>
> How I read that:
>
> "subversion" "dev release for 1.1.0" , which might/will be stable some day.
Glad I'm not the only one who read it that way. :-)
> So, I propose that the "dev" will prefix release number, in that way
> the first thing that will hit your brains is that this is "dev",
> after that you will find out the release number, package format, etc..
>
> subversion-dev-1.1.0.tar.gz, subversion-dev-1.1.0.rpm...
If we're going to make development releases, I think I prefer this way.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Ahh. When I read
> http://www.contactor.se/~dast/svn/archive-2003-12/0114.shtml I misread
> "Jan" as "Jun", and thought we were in for a six-month haul. I was
> certainly figuring we'd branch when we were closer.
+Whew+.
> If we think we can stabilize in one to two months, then sure, make a
> branch.
I do, yeah. A surprise showstopper at this point would be,
well... surprising.
> See my comments in response to him. I don't like it, Branko doesn't
> like it, and I think it's based on a preconception I disagree with (that
> we'll make releases off the trunk and not off of a stable branch).
Gotcha. Will write a separate mail about that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 19:08, kfogel@collab.net wrote:
> IMHO we are looking at weeks, not months, for this stabilization
> branch. Maybe not 2-6 weeks, but probably 4-8 weeks.
Ahh. When I read
http://www.contactor.se/~dast/svn/archive-2003-12/0114.shtml I misread
"Jan" as "Jun", and thought we were in for a six-month haul. I was
certainly figuring we'd branch when we were closer.
If we think we can stabilize in one to two months, then sure, make a
branch.
[Regarding Fitz's versioning proposal:]
> Would this method alleviate your concerns about having clearly
> labelled releases, Greg (Hudson)?
See my comments in response to him. I don't like it, Branko doesn't
like it, and I think it's based on a preconception I disagree with (that
we'll make releases off the trunk and not off of a stable branch).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Julian Foad <ju...@btopenworld.com>.
Jani Averbach wrote:
> On 2003-12-04 18:08-0600, kfogel@collab.net wrote:
>
>>Regarding that other topic, numbering schemes:
[...]
> However, may I introduce my own proposal? =)
[...]
> So, I propose that the "dev" will prefix release number, in that way
> the first thing that will hit your brains is that this is "dev",
> after that you will find out the release number, package format, etc..
>
> subversion-dev-1.1.0.tar.gz, subversion-dev-1.1.0.rpm...
Unfortunately the form "subversion-devel-1.1.0.rpm" is already taken to mean a package of libraries, header files, etc., that enables the user to develop software that links to Subversion. (And no, you can't argue that "dev" is different from "devel". :-)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2003-12-04 18:08-0600, kfogel@collab.net wrote:
>
> Regarding that other topic, numbering schemes:
>
...
First of, I am happy with even/odd scheme - users have to always find
out what is the stable version and what is the development version (if
there is any). If you just start poking around ftp server, and grab
what ever you first find, you are digging blood from your
nose. Moreover, what ever the schema will be, it should be documented
very top of README/INSTALL so I really don't see an issue here.
However, may I introduce my own proposal? =)
>
> Thus we'd have a stable maintenance line like this
>
> subversion-1.0.0.tar.gz
> subversion-1.0.1.tar.gz
> subversion-1.0.2.tar.gz
>
> And development releases like this:
>
> subversion-1.1.0-dev.tar.gz
> subversion-1.1.1-dev.tar.gz
> subversion-1.1.2-dev.tar.gz
>
How I read that:
"subversion" "dev release for 1.1.0" , which might/will be stable some day.
So, I propose that the "dev" will prefix release number, in that way
the first thing that will hit your brains is that this is "dev",
after that you will find out the release number, package format, etc..
subversion-dev-1.1.0.tar.gz, subversion-dev-1.1.0.rpm...
In general, I am against that "dev" tag, and definitely happy with
even/odd schema, and +1 for it.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> > First, I talked to some people who've had more experience managing
> > software releases (Jack Repenning and Greg Stein among others)
>
> I have seven years of job experience as a release engineer, if we're
> using personal qualifications as a means of justification.
Well, yes, it does make a difference for me anyway. This is one of
those areas where experience counts for a lot. (When I wrote "more
experience", I meant more than me.)
> This kind of reasoning works when you're looking at stabilizing a
> release for 2-6 weeks. When you're stabilizing for six months, you
> really have to do that on the trunk. I've seen this go bad; too many
> developers stick with the trunk and the release doesn't get enough
> attention, or (less likely) too many developers stick with the release
> branch and the trunk festers with changes whose brokenness isn't
> exposed.
>
> After we go into beta, we should discourage people from making
> medium-impact changes between then and release-candidate time, unless
> they can justify that the change must go into 1.0. People can make
> feature branches if they must.
>
> After the 1.0 release, it hopefully won't require anything like six
> months of stabilization for future releases, so this will be less of an
> issue. (And if it is an issue, then we can slow down development on the
> trunk just as I'm proposing we do now.)
Ah, I think we have some mismatched assumptions here.
IMHO we are looking at weeks, not months, for this stabilization
branch. Maybe not 2-6 weeks, but probably 4-8 weeks. We don't get a
lot of showstopper issues anymore; we have the occasional null pointer
brainos and such, but not core design issues (not for pre-1.0 anyway).
I'd be totally shocked if we needed 6 months to stabilize, based on
the state of Subversion today.
I think it's okay for developer attention to be mostly focused on the
trunk. The release branch doesn't need developer attention so much as
it needs user exposure -- that's why we'd make interim releases only
from the branch. (Developers will still build and test trunk, of
course, so it won't be completely unexercised during this time.)
So the penalty of having this branch may not be as high as you think.
However, If other developers are as ready as you to focus mainly on
1.0-stabilization, then I guess we could forego the branch and just do
it in trunk. We do need to make a clean partition between
stabilization and ongoing development at some point; whether that
partition starts slightly before the 1.0 release, or just at the 1.0
release, is less important, I suppose.
Regarding that other topic, numbering schemes:
Some people have suggested a modified version of the "odd==dev,
even==stable" scheme whereby the dev releases actually get the word
"-dev" in their name, so it's obvious that they're bleeding edge.
(The stable releases don't need a corresponding "stable" in their
name, because you don't need to warn someone that they're about to
install stable software.)
Thus we'd have a stable maintenance line like this
subversion-1.0.0.tar.gz
subversion-1.0.1.tar.gz
subversion-1.0.2.tar.gz
And development releases like this:
subversion-1.1.0-dev.tar.gz
subversion-1.1.1-dev.tar.gz
subversion-1.1.2-dev.tar.gz
This rocks, +1, etc, I only wish I'd proposed it in my original mail :-).
Would this method alleviate your concerns about having clearly
labelled releases, Greg (Hudson)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 13:15, kfogel@collab.net wrote:
> First, I talked to some people who've had more experience managing
> software releases (Jack Repenning and Greg Stein among others)
I have seven years of job experience as a release engineer, if we're
using personal qualifications as a means of justification.
> and they made the point that it's a lot easier to set termination
> conditions for a branch. The branch gives the release manager more
> freedom to make stabilization decisions. For example, there have been
> a whole lot of medium-impact commits in the last few weeks on trunk.
> If this trend continues, we would face a choice between discouraging
> people from doing that work, or having lots of code churn just when
> we're trying to stabilize for release.
This kind of reasoning works when you're looking at stabilizing a
release for 2-6 weeks. When you're stabilizing for six months, you
really have to do that on the trunk. I've seen this go bad; too many
developers stick with the trunk and the release doesn't get enough
attention, or (less likely) too many developers stick with the release
branch and the trunk festers with changes whose brokenness isn't
exposed.
After we go into beta, we should discourage people from making
medium-impact changes between then and release-candidate time, unless
they can justify that the change must go into 1.0. People can make
feature branches if they must.
After the 1.0 release, it hopefully won't require anything like six
months of stabilization for future releases, so this will be less of an
issue. (And if it is an issue, then we can slow down development on the
trunk just as I'm proposing we do now.)
> > > This is essentially the "even==stable, odd==dev" scheme that many
> > > other projects use.
> >
> > ... which is confusing as hell to the uninitiated. -0.9 on such a
> > numbering scheme.
>
> It sounds like the fundamental question here is: are we going to
> maintain a separate stable line or not?
Uh, that is a fundamental question, yes, but it has nothing to do with
even==stable, odd=dev.
> If you think a separate stable line is a good idea, then the rest is
> details. If you don't like the even/odd thing, I'm all ears for a
> better scheme. I considered others, some of which included the words
> "dev" and "stable" in the release names themselves. Eventually I
> ended up back at the even/odd system, but maybe there's some really
> good solution I just didn't think of.
Nothing's going to be perfect, but I don't consider it acceptable to
have a version number like "1.1.6" and the user is just supposed to know
that that's not a real, stable release because the middle number is odd.
I think we should strongly consider the option of, after 1.0, not
putting out version-numbered-releases which aren't part of a stable
branch. So we can have "1.1 beta 1" or "1.1rc1" for pre-releases, and
"1.1.1" for releases, but we can't have "post-1.1 version 10" for
something on the trunk which happens to postdate the 1.1 branchpoint.
If we do want to release tarballs from the trunk, we call them
"snapshots" and label them by revision number
(svn-snapshot-r9866.tar.gz).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> In http://www.contactor.se/~dast/svn/archive-2003-10/0128.shtml
> you proposed the same plan, but later appeared to concede that you were
> happy to stabilize on the trunk. I continue to favor stabilizing on the
> trunk; otherwise, we run the risk of having a long beta period where the
> stable branch diverges dramatically from the trunk, and our resources
> are divided between them.
Yes, I originally hoped we could do it all from trunk. (Sorry, I
should have referred to that earlier mail and said explicitly that I
was contradicting it. Due to travel constraints, I have a very slow
box at the moment, which is discouraging me from doing such extra
digging.)
Two things made me think again that we should use a branch:
First, I talked to some people who've had more experience managing
software releases (Jack Repenning and Greg Stein among others), and
they made the point that it's a lot easier to set termination
conditions for a branch. The branch gives the release manager more
freedom to make stabilization decisions. For example, there have been
a whole lot of medium-impact commits in the last few weeks on trunk.
If this trend continues, we would face a choice between discouraging
people from doing that work, or having lots of code churn just when
we're trying to stabilize for release.
The other thing was the realization that, if we're going to be
maintaining a stable line anyway, isolated from new feature
development, then we might as well start that line before the release.
The stability discipline isn't something you want to impose right
*after* 1.0 comes out, but rather before.
> > This is essentially the "even==stable, odd==dev" scheme that many
> > other projects use.
>
> ... which is confusing as hell to the uninitiated. -0.9 on such a
> numbering scheme.
It sounds like the fundamental question here is: are we going to
maintain a separate stable line or not?
I think we should. Not everyone wants or needs the bleeding edge all
the time, yet others do need the latest development code. I think
it's not by accident that so many widely-used projects have solved
this the same way.
If you think a separate stable line is a good idea, then the rest is
details. If you don't like the even/odd thing, I'm all ears for a
better scheme. I considered others, some of which included the words
"dev" and "stable" in the release names themselves. Eventually I
ended up back at the even/odd system, but maybe there's some really
good solution I just didn't think of. There is an inherent complexity
in maintaining separate stable and dev lines, though, and we can't
entirely paper over that.
If, on the other hand, you don't think we should maintain separate and
dev lines after each major release (such as 1.0), then let's talk
about that, as it's the real issue here.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 4, 2003, at 3:58 PM, Greg Hudson wrote:
> On Thu, 2003-12-04 at 18:41, Brian W. Fitzpatrick wrote:
>> OK, so how about if we stick to the even/odd convention, plus we
>> include either the string 'dev' or 'unstable' in development
>> releases?
>
> Well, it's not totally anathema to me, but it strikes me as ugly and I
> don't see what it buys us.
> I reiterate that we should consider limiting ourselves to making
> version-numbered releases on stable branches only, and not making
> "development" releases. If you look at the larger body of free
> software
> projects out there, most of them do not make a frequent practice of
> making development releases after they reach 1.0. The big example of a
> project which does so is the Linux kernel, which historically hasn't
> had
> a publically accessible repository to pull from. (And it has much less
> frequent development releases now that it does have such a repository.)
Well, I don't think that we should roll releases from the development
track until it's taken shape and we're looking for a broader set of
testers prior to going to a release candidate.
Basically, once we declare a 1.0 release, I don't see a need to roll a
dev tarball for quite some time (at the very least, a few months).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Thu, 2003-12-04 at 18:41, Brian W. Fitzpatrick wrote:
>
>
>>OK, so how about if we stick to the even/odd convention, plus we
>>include either the string 'dev' or 'unstable' in development
>>releases?
>>
>>
>
>Well, it's not totally anathema to me, but it strikes me as ugly and I
>don't see what it buys us.
>
>I reiterate that we should consider limiting ourselves to making
>version-numbered releases on stable branches only, and not making
>"development" releases.
>
+2 (both hands)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Colin Watson <cj...@flatline.org.uk>.
On Thu, Dec 04, 2003 at 08:56:16PM -0500, Greg Hudson wrote:
> In my opinion? 1.1.beta1, 1.1.beta2, etc. When the beta period is done
> and the release is ready to unleash upon the unwashed masses, you
> release 1.1.0, and when you discover the horrible security hole in 1.1.0
> that you need to patch, you release 1.1.1. (This is compatible with
> RPM, incidentally. 1.1.beta1 is less than 1.1.0 is less than 1.1.1.)
It's not compatible with dpkg, though:
$ dpkg --compare-versions 1.1.beta1 lt 1.1.0
$ echo $?
1
Textual/beta-style version numbers are a bit of a headache to make
portable across packaging systems, so I tend to feel they're best
avoided where possible.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Mason Thomas <ml...@sbcglobal.net>.
On Fri, Dec 05, 2003 at 09:37:26AM -0800, Kevin Pilch-Bisson wrote:
>
> > -----Original Message-----
> > From: Sander Striker [mailto:striker@apache.org]
> > Sent: Friday, December 05, 2003 2:33 AM
> > To: dev@subversion.tigris.org
> > Subject: Re: 0.35 => Beta => 1.0 schedule
> >
[snip]
> >
> Snip rest of Sanders proposal.
>
> I don't like the idea of using -dev in the name, so just to add to the mix,
> here's my proposal.
>
> Why don't we have:
> * released versions with version numbers.
> * snapshot releases, with just a datestamp or a revision number.
>
> So you would have subversion-1.0.tar.gz, and
> subversion-unstable-r12860.tar.gz
>
> I think this scheme avoids the confusion about version numbers, and makes it
> clear that this is an unstable release?
>
> -- Kevin.
An added benefit of using a timestamp (e.g., subversion-20031205.tar.gz)
is that the end user will have some idea how bleeding edge that
development version is. It is more difficult to know if r12860 is from
yesterday, a month ago or ...? And if the user is able to find that out,
they are probably also able to compile the most recent revision
themselves :-) The timestamp might also satisfy dpkg's sorting
criteria?
-Mason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: 0.35 => Beta => 1.0 schedule
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
> -----Original Message-----
> From: John Peacock [mailto:jpeacock@rowman.com]
> Sent: Friday, December 05, 2003 9:49 AM
> To: Kevin Pilch-Bisson
> Cc: dev@subversion.tigris.org
> Subject: Re: 0.35 => Beta => 1.0 schedule
>
> Kevin Pilch-Bisson wrote:
>
> > Why don't we have:
> > * released versions with version numbers.
> > * snapshot releases, with just a datestamp or a revision number.
> >
> > So you would have subversion-1.0.tar.gz, and
> > subversion-unstable-r12860.tar.gz
> >
> > I think this scheme avoids the confusion about version numbers, and
> makes it
> > clear that this is an unstable release?
> >
>
> What does 'svn version' report in the unstable snapshots? This also
> doesn't
> help packagers at all (since they may have different rules to play by).
>
Svn version can say "svn, version snapshot (r12860)"
Packagers can then have svn packages, and svn-snapshot packagers. People
who want the bleeding edge can go look for the -snapshot packages.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by John Peacock <jp...@rowman.com>.
Kevin Pilch-Bisson wrote:
> Why don't we have:
> * released versions with version numbers.
> * snapshot releases, with just a datestamp or a revision number.
>
> So you would have subversion-1.0.tar.gz, and
> subversion-unstable-r12860.tar.gz
>
> I think this scheme avoids the confusion about version numbers, and makes it
> clear that this is an unstable release?
>
What does 'svn version' report in the unstable snapshots? This also doesn't
help packagers at all (since they may have different rules to play by).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: 0.35 => Beta => 1.0 schedule
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
> -----Original Message-----
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Friday, December 05, 2003 2:33 AM
> To: dev@subversion.tigris.org
> Subject: Re: 0.35 => Beta => 1.0 schedule
>
> On Fri, 2003-12-05 at 02:56, Greg Hudson wrote:
> > On Thu, 2003-12-04 at 19:56, kfogel@collab.net wrote:
> > > ... but as they approach a new release, many projects *do* start
> > > releasing bleeding edge tarballs for testing.
> >
> > Right... but the key thing is that these are testing releases in
> > preparation for a new stable release, and their version numbers should
> > reflect this. Also, we should branch for 1.1 before we start putting
> > out tarballs for testing for 1.1, and we should make our testing
> > tarballs off of the 1.1 branch, not the trunk
>
> Sheesh, that's some thread...
Sure is.
>
> I'll add my thoughts. First of all, the -dev prefix in httpd is there
> to tell you the code you are using, was not released as stable when you
> grabbed and built it. svn --version uses this property aswell AFAICT,
> and I rather like it. Greg Hudson mentioned people stripping the -dev,
> but IMO, that's the same as just arbitralily modifying the version
> header. If this is something that people frequently do, that's a
> problem in itself.
My personal problem with the -dev approach that we/httpd/apr use is that I
can never remember whether 1.0-dev is dev leading toward 1.0, or based on
1.0.
>
Snip rest of Sanders proposal.
I don't like the idea of using -dev in the name, so just to add to the mix,
here's my proposal.
Why don't we have:
* released versions with version numbers.
* snapshot releases, with just a datestamp or a revision number.
So you would have subversion-1.0.tar.gz, and
subversion-unstable-r12860.tar.gz
I think this scheme avoids the confusion about version numbers, and makes it
clear that this is an unstable release?
-- Kevin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Sander Striker <st...@apache.org>.
On Fri, 2003-12-05 at 02:56, Greg Hudson wrote:
> On Thu, 2003-12-04 at 19:56, kfogel@collab.net wrote:
> > ... but as they approach a new release, many projects *do* start
> > releasing bleeding edge tarballs for testing.
>
> Right... but the key thing is that these are testing releases in
> preparation for a new stable release, and their version numbers should
> reflect this. Also, we should branch for 1.1 before we start putting
> out tarballs for testing for 1.1, and we should make our testing
> tarballs off of the 1.1 branch, not the trunk
Sheesh, that's some thread...
I'll add my thoughts. First of all, the -dev prefix in httpd is there
to tell you the code you are using, was not released as stable when you
grabbed and built it. svn --version uses this property aswell AFAICT,
and I rather like it. Greg Hudson mentioned people stripping the -dev,
but IMO, that's the same as just arbitralily modifying the version
header. If this is something that people frequently do, that's a
problem in itself.
Having a development and stable branch is in some ways a delight and
at other times painful. It all depends on how much developer energy
is available and how many people are interested in doing backports.
Note that with httpd we have a 2.1 branch (== CVS HEAD) and a 2.0
branch, the 2.0 branch only receives backports. IOW, all development
happens on 2.1 first. This keeps 2.0 nice and stable, which should
allow easier releases of 2.0.
I could see us have a similar setup in subversion by renaming trunk to
devel and branching 1.0 to svn-1.0. We can introduce 1.1 either by
branching svn-1.0 to svn-1.1 at some point, doing a bunch of backports
of devel, or, my preference, branch devel to svn-1.1.
Release wise, we can always do a branch from svn-x.y to svn-x.y.z,
change the version string (stripping the -dev), and tagging it as
svn-x.y.z. If we feel a release should be beta or alpha even, we
should reflect that in the version and the tag.
Development releases could be just tarballs of snapshots, created
directly from devel. These will all be named svn-x.y.z-dev, because
when we feel devel is ready for the masses, we branch it to svn-x.y
and start doing (alpha, beta, GA) releases from there. Ofcourse
devel is bumped up a minor number after the branch (or a major number).
With this scheme there is no need to have even/odd numbering of
versions. devel promotes to stable, and devel gets a the next number.
The new stable branch doesn't get a version number change just because
it branched from devel.
Thoughts?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Colin Watson <cj...@flatline.org.uk>.
On Fri, Dec 05, 2003 at 12:34:23PM -0500, Greg Hudson wrote:
> In another message, Colin Watson said of my proposed scheme:
> > It's not compatible with dpkg, though:
>
> I'm told this is a cause of some amount of consternation in Debian,
> leading to package version numbers like "1.2.99-1.3beta3", where 1.2.99
> is a completely ficitious version number designed to sort correctly.
> I'm also told that there has been some discussion of adding a version
> character which sorts lower than any other character, such that
> "1.1~beta1" would be less than "1.1", but I don't know the status of
> that proposal.
This is all true, and with any luck will resolve several problems; last
time I looked at this I think either choice of ordering resulted in
pathological cases somewhere, so it's hard to win without something like
~.
~ has been implemented in dpkg and apt, I believe, but we can't use it
until after the next stable release.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Ben Reser <be...@reser.org>.
On Sat, Dec 13, 2003 at 09:54:00AM -0500, Greg Hudson wrote:
> Stable releases are named subversion-x.y.z, no odd/even
> Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
> (or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
> Snapshots off the trunk are named subversion-snapshot-rXXXXX
> We discourage binary packaging of anything other than stable releases
>
> So, we get:
>
> subversion-snapshot-r10135 from trunk
> subversion-snapshot-r10242 from trunk
> <branch point for 1.1>
> subversion-beta-1.1-r10321 from branch
> subversion-snapshot-r10400 from trunk
> subversion-beta-1.1-r10412 from branch
> subversion-1.1.0 from branch
>
> I like this because:
>
> * Stable releases live in a different version space from everything
> else, and that version space reflects the branch structure which exists
> for them. Odd/even would be a distortion of the branch structure.
>
> * It's easy to identify where unstable releases came from in the
> repository, and what they are.
I can't understand why we would want to do snapshots from the trunk?
Is there any real reason to do this? A snapshot from the trunk isn't
going to be particularly special... All it means is someone did an
export, followed the release procedures to some degree (no branching,
no changing the version, but running autogen etc...). Further, what
exactly is the point for releasing a snapshot that you don't want people
to package? I can understand a beta, you want people to test it and to
some degree that means packaging.
As a packager I can tell you the following is going to happen. If you
put up a snapshot tarball, it'll end up showing on sites like freshmeat
or end users will just find it on your website, then I'll get several
emails asking when I'm going to be packaging the snapshot. Some
packagers will either give in and just do it or tell people to go away.
Packagers need to package betas however, if for no other reason than to
simply get a chance to find errors in your installation routines that
create problems for packaging. But also to allow them to be prepared
for the release of the new version relatively soon after you do the
release.
You are right however that kfogel's proposal would lead to non-linear
version numbers. Which would be a real nightmare from a packaging
standpoint. Somehow I missed that when I read his email earlier. But
that's just not acceptable. I'd end up having to use epoch's on the
rpms (which I hate doing because to the end user it seems magical that
1.1.1 is upgrading over 1.3.1)
Drop the snapshot releases and I guess I like your proposal a little
better. Though honestly I'm not sure I'm fond of trying to include repo
revisions in the package names. But if it avoids a versioning nightmare
I guess I can live with it.
+1 for this without snapshots
-1 for kfogel's proposal that I previously +1'ed.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Ben Reser <be...@reser.org>.
On Fri, Dec 12, 2003 at 03:07:00PM -0600, kfogel@collab.net wrote:
> On to the proposal:
>
> Let's use "odd==unstable,even=stable" in the minor numbers, but with
> an "unstable-" *prefix* on all the odd-numbered releases. That way,
> users don't need to know about the even/odd thing. The unstable
> releases will always be clearly marked as unstable.
+1 this works great.
> One objection that was raised agains "-unstable" as a suffix is that
> non-numeric suffixes might make packaging more difficult. I'm not
> sure how severe that problem is, but anyway it's probably less severe
> when the word is a prefix. Also, we don't really want to optimize for
> packaging of unstable releases, I would think.
Won't matter. The problem with the words being in the release is
compromised of when 1.1-unstable eventually becomes 1.1. If someone
packages an unstable version it can show as newer than 1.1. There are
of course ways around this in most packaging systems. However, your
proposal makes this issue pretty much moot.
The only question then is if packagers will mark 1.1 packages as
unstable or for that matter if they should even be packaging them. But
really that's up to the distro/project's policies and really is of no
consequence to you guys.
Besides as you pointed out if someone does with the odd/even system you
can recognize right away that it is an unstable package when someone
comes around asking for help with it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-12-05 at 16:52, Greg Stein wrote:
> 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.
We are ever so close to agreement... but we do need to think about what
happens for the 4-8 weeks after we branch to stabilize for 1.1.
"subversion-snapshot-r8869" works great for a snapshot off the trunk,
but not so much for a not-yet-stabilized release off the 1.1 branch. I
can live with subversion-1.1.beta1, subversion-1.1.0-beta (such that the
first vetted release is subversion-1.1.5 or something),
subversion-1.1.snapshot-r8869, subversion-snapshot-1.1-r8869, or
whatever.
As Fitz pointed out on IRC, we don't need to decide this until we
actually branch for 1.1. But I'd actually kind of like to nail this
down, put it into HACKING, and never have to argue about it again. (I'm
such an optimist.)
(Oh, and please put me on your list of addresses not to send
auto-responses to.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-12-06 at 21:41, Justin Erenkrantz wrote:
> I think that is a wrong way to go about it. How does a snapshot relate to
> the latest released version?
I don't think it's terribly important that they be easily related. If
we branch for 1.1, then put out a trunk snapshot, then put out the 1.1.0
release, then the trunk snapshot may have features not present in 1.1.0,
but may not have bugfixes present in 1.1.0. Should it look newer or
older?
> Then, I don't believe it would be called svn 2.0 if it has the same ABI as
> 1.0.
So, let's say that something forces us to change the libsvn_client major
version number from 1 to 2. Are you saying we should bump the major
version on every other library we have, just to stay in sync? That
seems awfully expensive.
> I believe that not having an ABI versioning system or not making the
> principal version be the ABI version is going to engage the wrath from
> third-parties that are aiming at moving targets. We got flamed in
> httpd-land for breaking things without an ABI contract - we learned and
> now have explicit rules - only now are vendors starting to support 2.0
> correctly. I believe Subversion should learn from those experiences.
Nobody's saying we shouldn't have ABI versioning.
> Also, splitting ABI versions from the 'real' version is going to be a path
> fraught with extreme confusion. 'SVN 1.5 with ABI 1.2.3' Ick. -- justin
For fun, try running this script on any RPM-based system:
#!/bin/sh
cd /usr/lib
for lib in *.so.*.*.*; do
libname=`expr "$lib" : '\(.*\)\.so.*'`
libver=`expr "$lib" : '.*\.so\.\(.*\)'`
pkg=`rpm -qf $lib`
pkgname=`expr "$pkg" : '\(.*\)-[^-]*-.*'`
pkgver=`expr "$pkg" : '.*-\([^-]*\)-.*'`
printf "%-40s %-20s %s\n" "$libname ($pkgname)" "$libver" "$pkgver"
done
Then run the output through
awk '{print $3 == $4}' | sort | uniq -c
On my machine I get 27 matches and 193 mismatches. (A few of the
mismatches are actually loose matches, but not many.) By and large,
shared library versions do not match package versions. If this path is
fraught with extreme confusion, then we are already quite confused.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
>Also, splitting ABI versions from the 'real' version is going to be a path
>fraught with extreme confusion. 'SVN 1.5 with ABI 1.2.3' Ick. -- justin
>
>
We've already split the ABI version and the release version, just like
APR has. So we have, for example, libsvn_subr-1.so, where the "1" is the
ABI version. We'll also have the same _API_ compatibilty rules as APR,
and those rules define what the release version number means in terms of
(both API and ABI) compatibility.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
> On Sat, 2003-12-06 at 02:16, Justin Erenkrantz wrote:
>> As John pointed out, what would 'svn --version' say under this scheme?
>> Or,
>> would we only have x.y.z for stable releases?
>
> This question was answered by Kevin in
> <http://www.contactor.se/~dast/svn/archive-2003-12/0257.shtml>. "svn,
> version snapshot (r12860)"
I think that is a wrong way to go about it. How does a snapshot relate to
the latest released version? Remember that we're saying that 'svn
--version' on official releases don't have a revnum in their version
either.
I'd like to be able to correlate the version information by looking at the
output of version in the svn binary. Kevin's strategy doesn't allow for
that. Hence, we need some point of reference.
>> How about version compatibility and binary compatibility rules? They
>> have to
>> apply at all times once 1.0 hits.
>
> Those seem orthogonal.
I disagree. The ABI versioning rules we have in place are directly tied
into version numbers, so they aren't orthogonal. Enforcing ABI versioning
without the x.y.z format is going to be painful. If we follow the x.y.z
format for ABI versioning, most dynamic linkers will play nice.
> I don't think we should tie our shared library version to our package
> version. It's possible that we'll want to release svn 2.0 without
> making incompatible changes to the ABI (perhaps we added distributed
> operation, but managed to do so by only adding things in a compatible
> fashion to the schema, working copy, and network protocols). It's also
Then, I don't believe it would be called svn 2.0 if it has the same ABI as
1.0. Perhaps we add the additional constraint that changes to the SVN
repos backend can occur on minor version updates (i.e. 1.0->1.1).
(Ambivalent about that though.) But, I believe the primary focus of the
version numbers should be about third-parties integrating with Subversion,
and the secondary focus is on users understanding what it means.
Hence, I believe our version numbers should be extremely tied in with the
binary compatibility rules. When we make a change that fits under the
minor category, we bump to 1.2 (under odd/even rules); when we make a
change that bumps the major version of the shared library, we go to 2.0.
That tells third-parties when they need to release a new version.
I believe that not having an ABI versioning system or not making the
principal version be the ABI version is going to engage the wrath from
third-parties that are aiming at moving targets. We got flamed in
httpd-land for breaking things without an ABI contract - we learned and
now have explicit rules - only now are vendors starting to support 2.0
correctly. I believe Subversion should learn from those experiences.
Also, splitting ABI versions from the 'real' version is going to be a path
fraught with extreme confusion. 'SVN 1.5 with ABI 1.2.3' Ick. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-12-06 at 02:16, Justin Erenkrantz wrote:
> As John pointed out, what would 'svn --version' say under this scheme? Or,
> would we only have x.y.z for stable releases?
This question was answered by Kevin in
<http://www.contactor.se/~dast/svn/archive-2003-12/0257.shtml>. "svn,
version snapshot (r12860)"
> > Summarizing my email... it is just what Kevin posted:
> >
> > * interim releases are revnum-labeled
> > * stable releases are version-labeled
>
> How about version compatibility and binary compatibility rules? They have to
> apply at all times once 1.0 hits.
Those seem orthogonal.
> Also, I'd think that the 'unstable' version *needs* a version number for DSOs;
> not having a version for the dynamic linker is going to piss it off. -- justin
I don't think we should tie our shared library version to our package
version. It's possible that we'll want to release svn 2.0 without
making incompatible changes to the ABI (perhaps we added distributed
operation, but managed to do so by only adding things in a compatible
fashion to the schema, working copy, and network protocols). It's also
possible that we'll want to change the shared library major version
without bumping our own major version number.
(As an aside, apologies for writing "Fitz" instead of "Kevin" in
previous mail. I don't know why I have so much trouble with those
names; they aren't similar at all.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Andy Whitcroft <ap...@shadowen.org>.
Locally we have been using CVS and laterly to version a lot of our own
tools. We often have three versions actively used and being bug fixed. I
have found that there are three issues here.
1) we tend to have a big hangup over the trunk as if it was something
special, really its the repository branch which represents the next major
release.
2) we have a big hangup about releasing at x.y.0.
3) regardless of version you always care which specific 'image' of the
source it was made from.
I think we should simply use the all the minor releases in order. 1.0.x is
the next release. When we cut that for 'stabilisation' create
branches/1.0; trunk is now effectively branches/1.1 (and perhaps there is
some sense in renaming it such as then a release would always be cut
against the same repository URL). Now any changes needed to stabalise the
1.0 branch would bump the patch release (on release of course). When the
powers to be are happy that release is 'blessed'. "1.0 is ready for
mainstream use starting at 1.0.2" or wherever it gets to. Really what I am
saying is that stability is a matter of blessing and not a version specific
thing?
As for the version number, I think you always need to know which 'build' a
binary is made. In CVS we had to manually maintain a build number, in SVN
we use the repository revision. I think this should be exposed always in
the version output (1.0.2 r9000) or similar. Then if someone has picked up
a 'trunk' release and compiled it then you know, even if it has a blessed
version number. That and the fact that the output is consistant.
Cheers.
-ap
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 5, 2003 1:52 PM -0800 Greg Stein <gs...@lyra.org> wrote:
> 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.
As John pointed out, what would 'svn --version' say under this scheme? Or,
would we only have x.y.z for stable releases?
> Summarizing my email... it is just what Kevin posted:
>
> * interim releases are revnum-labeled
> * stable releases are version-labeled
How about version compatibility and binary compatibility rules? They have to
apply at all times once 1.0 hits.
Also, I'd think that the 'unstable' version *needs* a version number for DSOs;
not having a version for the dynamic linker is going to piss it off. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by solo turn <so...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
> Here's some points of contention:
>
> * If we do make these unstable tarballs, we {would branch for a week
> or so first, like we do with 0.x releases now, in order to write a
> CHANGES file and catch serious bugs/would just document the really
> interesting new features and then make a snapshot of the trunk,
> because we won't have a population of users trying to use our
> unstable trunk releases for serious work like we do for 0.x
> releases}.
i would disagree in this point. the 1.0 users will be additional users.
if svn's quality stays like it is, the users using the 0.xx now will
continue to use trunk, whatever it is called.
why should one stay with 1.0, if a performant working copy, (re)merging
support, repository replication, certificate based authentication and
signature, and other features are missing? why should one stay with 1.0,
if svn itself is hosted with trunk, and will work as it does now?
but i think this is only true if there is binaries and self-hosting
at these versions (which guarantees that basic functionality is working
and no data is lost).
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2003-12-14 at 01:03, kfogel@collab.net wrote:
> Aha, there's a communications gap here. My assumption, which I should
> have made explicit, is that we don't release from two different dev
> lines simultaneously.
> That is, we wouldn't be trying to stabilize 1.2 (via the unstables or
> "betas" leading up to it) while at the same time making releases from
> trunk. There just wouldn't be trunk snapshots. We don't do them now,
> after all; is there a reason to start?
Initially I thought we wouldn't want to make any more releases from the
trunk at all; we'd make semi-frequent bugfix releases to the most recent
stable branch, and we'd infrequently branch for a new stable release,
and that would be it. But gstein disagreed, claiming that we'd want to
make trunk releases on a frequent basis, leading to the "svn-snapshot"
proposal. Having received disagreement on this point, I assumed that we
wanted a version numbering system that was permissive of both trunk and
branch releases at any time.
> I was only trying to linearize a linear release structure. If we're
> going to have a non-linear structure, then my proposal won't work :-).
Okay. I'll try to set some parameters, starting with what I think we
can all mostly agree on:
* We will have stable releases. The first one will be called 1.0 or
1.0.0. Releases leading up to 1.0 will be called 0.36, 0.37, etc..
* We will branch for some short period (4-8 weeks, perhaps) before
each stable release, to promote the stability of the release.
* During the period leading up to a stable release, we will release
tarballs from the branch for testing.
* During the period leading up to a stable release, we will NOT
release tarballs from the trunk, even if we have some cool new
feature there we want tested.
* It is important that non-stable releases are somehow labelled as
such. (Not 100% consensus here.)
Here's some points of contention:
* Between stable releases, we will {frequently/infrequently/never}
make unstable tarballs based on the trunk, with no expectation that
they would ever lead to a stable release.
* If we do make these unstable tarballs, we {would branch for a week
or so first, like we do with 0.x releases now, in order to write a
CHANGES file and catch serious bugs/would just document the really
interesting new features and then make a snapshot of the trunk,
because we won't have a population of users trying to use our
unstable trunk releases for serious work like we do for 0.x
releases}.
* If we do make these unstable tarballs, it is {good/bad} for them to
have similar-looking version numbers to testing versions leading up
to the next stable release. (Note that both Linux and GNOME,
the two most visible users of the odd/even convention, have warped
their version numbering so that testing releases look different from
trunk unstable releases. Linux is currently sitting at
2.6.0-test11,
and GNOME has been known to bump the last number to 90 or 100 in
order to indicate proximity to a coming even release.)
* We should {expect binary packagers to make .debs and .rpms of
unstable and/or testing releases, and try to help them/discourage
them from making .debs and .rpms of unstable and/or testing releases
and not worry if their lives become difficult if they do so}.
* We should {decide on our version numbering scheme based on first
principles/try to {roughly/strictly} emulate
{Linux/GNOME/BDB/Mozilla/*BSD/something else}}.
Karl's proposal (odd/even, with an "unstable" prefix on odd) is
compatible with having unstable trunk tarballs, is compatible with
branching for a week before unstable trunk tarballs, and puts unstable
trunk tarballs in the same version line as stable release testing
tarballs. Binary packages of unstable or testing tarballs could be made
using the same package name as the stable releases, and the version
numbering works out (a stable release supercedes period unstable
releases and is superceded by subsequent unstable releases). It roughly
resembles the Linux or GNOME schemes.
My proposal (no odd/even, unstable trunk releases prefixed by "snapshot"
and identified only by trunk revision number, testing releases prefixed
by "beta" and identified by X.Y branch and revision number) is
compatible with having unstable trunk tarballs, is not very compatible
with branching for a week before unstable trunk tarballs, and puts
unstable trunk tarballs in a different version line from stable release
testing tarballs. Binary packages of unstable or testing tarballs would
have to use different package names from stable releases, with conflict
markers so people can't install both at once. It roughly resembles KDE
or Mozilla or *BSD, though those projects almost always muck with the
version number rather than the prefix to indicate trunk-unstable or
release-testing tarballs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Marc Haisenko <ha...@webport.de>.
On Tuesday 16 December 2003 19:17, Greg Hudson wrote:
> On Tue, 2003-12-16 at 12:44, Marc Haisenko wrote:
> > Now what John meant (I think) is that Mozilla 1.4 and 1.5 are like Linux
> > 2.4.21 and 2.4.22
>
> But they aren't similar. There was Mozilla 1.4.1 for bugfixes. Mozilla
> 1.5 is so named because it has new features.
>
> (Linux sometimes does put new features into 2.4.x releases. But that
> seems like a weakness, not a strength. With Mozilla, you know that 1.5
> has new features relative to 1.4, and that 1.4.1 has only bugfixes
> relative to 1.4.)
Well, new features are also introduced in the stable tree of Linux, but none
are very dramatic.
Whatever. It really does not matter since it's just a matter of the developers
personal taste how they number their releases... if they'd liked they could
even give each release a name ;-)
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 12:44, Marc Haisenko wrote:
> Now what John meant (I think) is that Mozilla 1.4 and 1.5 are like Linux
> 2.4.21 and 2.4.22
But they aren't similar. There was Mozilla 1.4.1 for bugfixes. Mozilla
1.5 is so named because it has new features.
(Linux sometimes does put new features into 2.4.x releases. But that
seems like a weakness, not a strength. With Mozilla, you know that 1.5
has new features relative to 1.4, and that 1.4.1 has only bugfixes
relative to 1.4.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Marc Haisenko <ha...@webport.de>.
On Tuesday 16 December 2003 18:15, Greg Hudson wrote:
> > Because that is what the developers of each project have specified. The
> > Linux developers mandate that 2.4 and 2.6 are two different release
> > generations. Similarly, Mozilla 1.5 and 1.6 are defined by their
> > development team as two minor releases in the same generation.
>
> You're saying "because Mozilla has more frequent releases?" That has
> nothing to do with the version numbers. If Mozilla slowed down releases
> but kept their version numbering, then Mozilla 1.5 and Mozilla 1.6 would
> be just as different as Linux 2.4 and Linux 2.6. That would also hold
> true if Linux sped up their release cycle and made fewer changes between
> 2.4 and 2.6.
>
> (Your use of the word "generation" only served to confuse the issue for
> me. What's a "generation?" When Mozilla had bugfixes to make to 1.4,
> they put out 1.4.1, not 1.5.)
The Linux version numbering works as following: version with an even second
version number (2.0, 2.2, 2.4, 2.6) are "stable". This means that there
aren't any major changes in these lines, especially not API changes. Versions
with an odd second version number (2.1, 2.3, 2.5) are development version
which means they change a lot, even in dramatic ways. Once the dust settles
and Linus thinks a development version is getting stable it gets an even
version number again.
There were really dramatic changes between 2.4 and 2.6 including several API
changes, new Virtual Memory, new scheduler, etc. pp. These are VERY dramatic
changes when it comes to an OS kernel :-)
Now what John meant (I think) is that Mozilla 1.4 and 1.5 are like Linux
2.4.21 and 2.4.22, so that you can compare the amount of dramatic changes
would suggest that Mozilla 1.x is more like Linux 2.4.x and a future Mozilla
2.x would be more like a Linux 2.6.x
It's just different flavours of versioning. Especially commercial products
nowadays don't do any x.y releases any more and just say release x (like
Corel Draw 8, Corel Draw 9, ... even if the changes weren't very dramatic).
And in the OpenSource community you often see version numbers like 1.2.54pl2
or even more obscure numberings.
I maintain a Linux distro and had to write a small tool that compares version
number to tell which one is the bigger one... I can tell you this task is not
as trivial as it sounds :-)
It all comes down to what flavour of version numbers do the developers prefer.
And what they consider to be the version number of the "finished" product
containing all features. Like SubVersion devs always talk about the Holy 1.0,
which they consider to be the version number for the "finished" product...
other would say that 0.1 would be as good a number for the finished product
and coordinate their numbering accordingly...
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 15:19, John Peacock wrote:
> > Clearer, but contrary to what you said before, the version number does
> > not indicate what branch a build is from; 1.1.1 was made from trunk
> > while 1.1.42 was made for the 1.2 stabilization branch.
>
> 1.1.1 was branched from the trunk prior to release, yes. 1.1.42 was the last
> version released, so that will be will be reported (plus the revision number).
> The fact that eventually this branch may be used to cut 1.2.0 is besides the point.
You seem to be missing a key phase of the release process. Before we
cut 1.2.0, we will branch for 4-8 weeks. We will be making testing
tarballs from that branch perhaps every two weeks. What version numbers
will these tarballs have?
> > You have also left out what "svn --version" displays for a private build
> > made from the trunk after we have branched for 1.2 (but before we have
> > released 1.2).
>
> It will still display 1.1.42 [or whatever was the last release before 1.2.0 was
> cut] (plus the revision number), since 1.2.0 doesn't exist until 1.2.0 is
> released. The fact that in the repository there is a tag called "1.2.0" doesn't
> mean anything until it is released. We have to trust people not to update to
> the 1.2.0 tag until after we have officially released it (although, by 1.2.0 we
> will have ACL's to enforce that, right?).
So, it doesn't bother you that 1.1.42 (rXXXX) might contain significant
trunk changes not present in 1.2.0, even though 1.2.0 is a greater
version number than 1.1.42?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Clearer, but contrary to what you said before, the version number does
> not indicate what branch a build is from; 1.1.1 was made from trunk
> while 1.1.42 was made for the 1.2 stabilization branch.
1.1.1 was branched from the trunk prior to release, yes. 1.1.42 was the last
version released, so that will be will be reported (plus the revision number).
The fact that eventually this branch may be used to cut 1.2.0 is besides the point.
>
> You have also left out what "svn --version" displays for a private build
> made from the trunk after we have branched for 1.2 (but before we have
> released 1.2).
It will still display 1.1.42 [or whatever was the last release before 1.2.0 was
cut] (plus the revision number), since 1.2.0 doesn't exist until 1.2.0 is
released. The fact that in the repository there is a tag called "1.2.0" doesn't
mean anything until it is released. We have to trust people not to update to
the 1.2.0 tag until after we have officially released it (although, by 1.2.0 we
will have ACL's to enforce that, right?).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 14:30, John Peacock wrote:
> > svn releases from the trunk will display *what* version number? They
> > weren't released from a branch. They do not bear a linear relationship
> > to any release made from any branch.
> Here's a sequence of releases that may make my suggestion clearer:
> 1.0.0 - Yay!
> 1.1.0 (r8654) - first dev release 6 weeks later
> 1.1.1 (r8699) - second dev release 6 weeks later still
> 1.1.1 (r8722) - I built this from TRUNK the next Wednesday
> 1.1.2 (r8733) - another dev build on schedule
> 1.0.1 - Oops, a bug fix to the last official release
> ...
> 1.1.42 (r9100) - last beta release for next official release
> 1.2.0 - Yay
> Does this make anything clearer?
Clearer, but contrary to what you said before, the version number does
not indicate what branch a build is from; 1.1.1 was made from trunk
while 1.1.42 was made for the 1.2 stabilization branch.
You have also left out what "svn --version" displays for a private build
made from the trunk after we have branched for 1.2 (but before we have
released 1.2).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> svn releases from the trunk will display *what* version number? They
> weren't released from a branch. They do not bear a linear relationship
> to any release made from any branch.
That depends completely on what this thread eventually leads to. *My*
preference is that the Official Releases have an even second term, and any
development releases have the odd second term plus the actual revision number of
that build. There are objections to that, but I think it is the most useful schema.
The rate with which the version is incremented on the development releases
should correspond to exactly what has been happening with the current alphas
(with milestone releases). The actual procedure for releasing a dev release
should, in fact, include making a branch and releasing from there (not directly
from the trunk). But the point is that if I update to the trunk and build,
_both_ the revision and the most recent released version are useful markers.
Here's a sequence of releases that may make my suggestion clearer:
1.0.0 - Yay!
1.1.0 (r8654) - first dev release 6 weeks later
1.1.1 (r8699) - second dev release 6 weeks later still
1.1.1 (r8722) - I built this from TRUNK the next Wednesday
1.1.2 (r8733) - another dev build on schedule
1.0.1 - Oops, a bug fix to the last official release
...
1.1.42 (r9100) - last beta release for next official release
1.2.0 - Yay
This way, you know at a glance that "1.1.1 (r8722)" is mostly the same as
"1.1.1" but with a few more revisions applied. The big difference is that the
"Official" releases do not need the revision number as well. For packaging
purposes, those should probably be released as
subversion-1.0.0
subversion-dev-1.1.0
subversion-dev-1.1.0
subversion-dev-1.1.1
subversion-dev-1.1.2
...
subversion-dev-1.1.42
subversion-1.2.0
Note that my private build from TRUNK is not included here.
Does this make anything clearer?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 12:02, John Peacock wrote:
> I second/third the recommendation that 'svn --version' report a version based on
> what branch it was released from. "official releases" (which always come from a
> branch) will report a version soley based on the branch they were released from
> and svn releases from the trunk will display the revision number in addition to
> the version number.
svn releases from the trunk will display *what* version number? They
weren't released from a branch. They do not bear a linear relationship
to any release made from any branch.
> Because that is what the developers of each project have specified. The Linux
> developers mandate that 2.4 and 2.6 are two different release generations.
> Similarly, Mozilla 1.5 and 1.6 are defined by their development team as two
> minor releases in the same generation.
You're saying "because Mozilla has more frequent releases?" That has
nothing to do with the version numbers. If Mozilla slowed down releases
but kept their version numbering, then Mozilla 1.5 and Mozilla 1.6 would
be just as different as Linux 2.4 and Linux 2.6. That would also hold
true if Linux sped up their release cycle and made fewer changes between
2.4 and 2.6.
(Your use of the word "generation" only served to confuse the issue for
me. What's a "generation?" When Mozilla had bugfixes to make to 1.4,
they put out 1.4.1, not 1.5.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> But unless we change this number with every commit, such a version
> number would be vague at best and deceptive at worst. A user reports
> that their "svn --version" says 1.1.13, but it's not actually the 1.1.13
> tarball we put out, but a similar version on the trunk.
This is actually why Perl has a "Locally Applied Patches" section of 'perl -V'
so that the actual patch number that the Perl was built from can be reported.
> $ ./perl -v
>
> This is perl, v5.9.0 built for i686-linux
> (with 1 registered patch, see perl -V for more detail)
versus
> $ ./perl -Ilib -V
> Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 20173) configuration:
I second/third the recommendation that 'svn --version' report a version based on
what branch it was released from. "official releases" (which always come from a
branch) will report a version soley based on the branch they were released from
and svn releases from the trunk will display the revision number in addition to
the version number.
> This argument seems especially specious. Why is the difference between
> Linux 2.4 and Linux 2.6 inherently any larger than the diference between
> Mozilla 1.5 and Mozilla 1.6?
Because that is what the developers of each project have specified. The Linux
developers mandate that 2.4 and 2.6 are two different release generations.
Similarly, Mozilla 1.5 and 1.6 are defined by their development team as two
minor releases in the same generation.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> But unless we change this number with every commit, such a version
> number would be vague at best and deceptive at worst. A user reports
> that their "svn --version" says 1.1.13, but it's not actually the 1.1.13
> tarball we put out, but a similar version on the trunk.
It would have to say "1.1.13+" or "1.1.13M" or something.
> This argument seems especially specious. Why is the difference between
> Linux 2.4 and Linux 2.6 inherently any larger than the diference between
> Mozilla 1.5 and Mozilla 1.6?
Indeed.
Jim Blandy once asked: is it harder to learn to play the harpsichord
than a Coke can is cold when you take it out of the refrigerator?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-16 at 02:53, Justin Erenkrantz wrote:
> I go back to asking that we always have a version number reported in 'svn
> --version' even on the trunk.
But unless we change this number with every commit, such a version
number would be vague at best and deceptive at worst. A user reports
that their "svn --version" says 1.1.13, but it's not actually the 1.1.13
tarball we put out, but a similar version on the trunk.
> As I've said before, Greg H's suggestion
> doesn't allow for a version number to be reported, and I think that's a
> horribly frustrating scheme to work with as a user. Depending upon if you are
> on 'stable' or 'unstable', you will either get a x.y.z or rXXXX. I think it
> must be consistent.
Why? And, how many users do we really expect to be working with the
trunk at all? I think you're expecting life after 1.0 to be more
similar to life before 1.0 than it really will be.
> I dislike Mozilla's version scheme as I have no idea what's changed between
> 1.5 and 1.6. Is it a big change? Little change? With Linux-based schemes, I
> can quickly know that 2.4->2.6 is bound to be a 'large-ish' change with
> testing (2.5) in between. -- justin
This argument seems especially specious. Why is the difference between
Linux 2.4 and Linux 2.6 inherently any larger than the diference between
Mozilla 1.5 and Mozilla 1.6?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, December 14, 2003 12:03 AM -0600 kfogel@collab.net wrote:
> situation. Instead, let's try to concentrate on one line at a time,
> and deviate from that only when a serious bug in a stable release
> demands it.
+1 to your proposal.
I go back to asking that we always have a version number reported in 'svn
--version' even on the trunk. As I've said before, Greg H's suggestion
doesn't allow for a version number to be reported, and I think that's a
horribly frustrating scheme to work with as a user. Depending upon if you are
on 'stable' or 'unstable', you will either get a x.y.z or rXXXX. I think it
must be consistent.
The problem with adopting an rXXXX-only scheme means that we're back to a
linear ordering. However, I think you *can* map a non-linear ordering on the
x.y.z scheme (by enforcing odd/even rules), but we can't do that with rXXXX.
I dislike Mozilla's version scheme as I have no idea what's changed between
1.5 and 1.6. Is it a big change? Little change? With Linux-based schemes, I
can quickly know that 2.4->2.6 is bound to be a 'large-ish' change with
testing (2.5) in between. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by kf...@collab.net.
> The problem comes when we branch for the next stable release (1.2, in
> your proposal). Now we have to differentiate between beta releases of
> 1.2 and unstable releases on the trunk which happen to chronologically
> predate the release of 1.2. The even/odd scheme works against us; we
> could wind up with confusing release orders like:
>
> subversion-unstable-1.1.1
> subversion-unstable-1.1.2
> <branch point for 1.2>
> subversion-unstable-1.1.3 from branch
> subversion-unstable-1.3.0 from trunk
> subversion-unstable-1.1.4 from branch
> subversion-unstable-1.3.1 from trunk
> subversion-1.2.0 from branch
>
> By using odd/even, you are trying to linearize a fundamentally
> non-linear structure of releases, and the result is confusion. This is
> why Linux winds up with version numbers like 1.2.0-pre6 even though it
> uses odd/even.
Aha, there's a communications gap here. My assumption, which I should
have made explicit, is that we don't release from two different dev
lines simultaneously.
That is, we wouldn't be trying to stabilize 1.2 (via the unstables or
"betas" leading up to it) while at the same time making releases from
trunk. There just wouldn't be trunk snapshots. We don't do them now,
after all; is there a reason to start?
I was only trying to linearize a linear release structure. If we're
going to have a non-linear structure, then my proposal won't work :-).
The only time we'd have releases coming from two different lines would
be when we're releasing unstables (leading to a new stable release),
while simultaneously making a bugfix release from an existing stable
line. But bugfix releases are a different kind of beast: we just
branch the old release tag, apply the fix, test the heck out of it,
and release. The idea is that only very conservative changes go into
a bugfix release of a stable line anyway.
> So, let me counterpropose:
>
> Stable releases are named subversion-x.y.z, no odd/even
> Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
> (or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
> Snapshots off the trunk are named subversion-snapshot-rXXXXX
> We discourage binary packaging of anything other than stable releases
If we want all these kinds of releases going on simultaneously, a
system like this could work. But I don't think we want that
situation. Instead, let's try to concentrate on one line at a time,
and deviate from that only when a serious bug in a stable release
demands it.
I won't comment on the specifics of the counterproposal right now.
It's clear we need to first figure out the semantics of our release
structure, before we can agree on a syntax!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Hudson <gh...@MIT.EDU>.
Your proposal, much like gstein's, is flawed because it conflates
"unstable release off the trunk" with "not-yet-vetted release off a
release branch."
On Fri, 2003-12-12 at 16:07, kfogel@collab.net wrote:
> Also, many have commented that one problem with using words in a
> release number is that you don't know whether the word is leading to
> the current number, or the next number. E.g., is the series
> "1.1.1-unstable", "1.1.2-unstable", and so on, leading to "1.2.0", or
> to "1.1"?
This is clearer with "1.1.beta1", precisely because "beta" is very
different from "unstable." But we have other reasons not to like that
scheme, so, moving on:
> Let's use "odd==unstable,even=stable" in the minor numbers, but with
> an "unstable-" *prefix* on all the odd-numbered releases. That way,
> users don't need to know about the even/odd thing. The unstable
> releases will always be clearly marked as unstable.
The problem comes when we branch for the next stable release (1.2, in
your proposal). Now we have to differentiate between beta releases of
1.2 and unstable releases on the trunk which happen to chronologically
predate the release of 1.2. The even/odd scheme works against us; we
could wind up with confusing release orders like:
subversion-unstable-1.1.1
subversion-unstable-1.1.2
<branch point for 1.2>
subversion-unstable-1.1.3 from branch
subversion-unstable-1.3.0 from trunk
subversion-unstable-1.1.4 from branch
subversion-unstable-1.3.1 from trunk
subversion-1.2.0 from branch
By using odd/even, you are trying to linearize a fundamentally
non-linear structure of releases, and the result is confusion. This is
why Linux winds up with version numbers like 1.2.0-pre6 even though it
uses odd/even.
So, let me counterpropose:
Stable releases are named subversion-x.y.z, no odd/even
Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
(or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
Snapshots off the trunk are named subversion-snapshot-rXXXXX
We discourage binary packaging of anything other than stable releases
So, we get:
subversion-snapshot-r10135 from trunk
subversion-snapshot-r10242 from trunk
<branch point for 1.1>
subversion-beta-1.1-r10321 from branch
subversion-snapshot-r10400 from trunk
subversion-beta-1.1-r10412 from branch
subversion-1.1.0 from branch
I like this because:
* Stable releases live in a different version space from everything
else, and that version space reflects the branch structure which exists
for them. Odd/even would be a distortion of the branch structure.
* It's easy to identify where unstable releases came from in the
repository, and what they are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by kf...@collab.net.
A lot of useful observations have been made in this thread. We should
reach a conclusion in the next week or so, since 0.35 branches today
and is released next Friday.
Below, I'll offer a new proposal that takes these observations into
account. But before I do, a couple of points:
Greg Hudson is right that
> 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 think it's very important that unstable versions be clearly marked.
But we can do it fairly non-intrusively, by making the descriptive
word a prefix to the number instead of a suffix.
Also, many have commented that one problem with using words in a
release number is that you don't know whether the word is leading to
the current number, or the next number. E.g., is the series
"1.1.1-unstable", "1.1.2-unstable", and so on, leading to "1.2.0", or
to "1.1"?
In the scheme I'm about to propose, it would lead to 1.2.0, but the
important thing is, it doesn't matter if non-developers know the
number of the next release, as long as we meet one simple condition:
if a minor number ever appears with a modifying word, it never appears
*without* that word. If a plain "1.1" never exists, it can never be
downloaded.
On to the proposal:
Let's use "odd==unstable,even=stable" in the minor numbers, but with
an "unstable-" *prefix* on all the odd-numbered releases. That way,
users don't need to know about the even/odd thing. The unstable
releases will always be clearly marked as unstable.
For example, here is a series of releases in order:
[...]
subversion-unstable-1.1.1.tar.gz /* development release */
subversion-unstable-1.1.2.tar.gz /* development release */
subversion-unstable-1.1.3.tar.gz /* development release */
subversion-1.2.0.tar.gz /* stable release */
subversion-1.2.1.tar.gz /* bugfix to stable release */
subversion-unstable-1.3.0.tar.gz /* development release */
subversion-unstable-1.3.1.tar.gz /* development release */
subversion-unstable-1.3.2.tar.gz /* development release */
subversion-1.4.0.tar.gz /* stable release */
subversion-1.4.1.tar.gz /* bugfix to stable release */
subversion-1.4.2.tar.gz /* bugfix to stable release */
subversion-unstable-1.5.0.tar.gz /* development release */
[...]
(The unstable tarballs will unpack into directories named
"subversion-unstable-X.Y.Z/", of course.)
I think users are unlikely to get confused and think that "1.1.X"
might follow "unstable-1.1.X", but even if they did, they won't ever
be tempted to download such a tarball, because no release named just
"1.1.X" will ever be made. That whole line will always have the
"unstable-" prefix, until one day 1.2.0 appears.
With this scheme, anyone looking at a set of releases can tell
immediately
a) What the set's ordering is
b) Which ones are considered unstable
And as for developers, even if someone leaves off the "unstable" in a
bug report, *we* will know from looking at the number that they are
using an unstable release.
One objection that was raised agains "-unstable" as a suffix is that
non-numeric suffixes might make packaging more difficult. I'm not
sure how severe that problem is, but anyway it's probably less severe
when the word is a prefix. Also, we don't really want to optimize for
packaging of unstable releases, I would think.
Another proposal was to use revision numbers as a fourth component in
the release number. I don't like that because it's hard (in a deep
way) to choose a revision that corresponds exactly to the set of
changes we're releasing, especially when releasing from a branch. And
without a descriptive word, it's still not completely clear that the
release is unstable, so why bother?
This new system wouldn't kick in until after 1.0 is out, by the way.
While we're on the "1.0-stabilization" branch, we just continue to
release 0.36, 0.37, etc, as necessary. Everyone's used to that
system, and since we won't yet have made a "1.0" announcement, there's
no more danger of someone thinking the software is stable now than
there was a week ago, or a month ago.
Granted that there are as many different release numbering systems as
grains of sand in the sky or stars on the beach: if you can live with
this, please say so, and if you absolutely can't, please say why.
When we settle, I'll document it all in HACKING of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
version numbering (was: 0.35 => Beta => 1.0 schedule)
Posted by Greg Stein <gs...@lyra.org>.
[ 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
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
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 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).
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.
In another message, Colin Watson said of my proposed scheme:
> It's not compatible with dpkg, though:
I'm told this is a cause of some amount of consternation in Debian,
leading to package version numbers like "1.2.99-1.3beta3", where 1.2.99
is a completely ficitious version number designed to sort correctly.
I'm also told that there has been some discussion of adding a version
character which sorts lower than any other character, such that
"1.1~beta1" would be less than "1.1", but I don't know the status of
that proposal.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 04, 2003 at 08:56:16PM -0500, Greg Hudson wrote:
> On Thu, 2003-12-04 at 19:56, kfogel@collab.net wrote:
> > ... but as they approach a new release, many projects *do* start
> > releasing bleeding edge tarballs for testing.
>
> Right... but the key thing is that these are testing releases in
> preparation for a new stable release, and their version numbers should
> reflect this. Also, we should branch for 1.1 before we start putting
> out tarballs for testing for 1.1, and we should make our testing
> tarballs off of the 1.1 branch, not the trunk
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.
> > But at some point, IMHO sooner rather than later, we'll want to make
> > dev tarballs available again, and when we do, they'll need names.
> > What should those names be?
I think that we'll have, say, a dozen dev/test release tarballs. Maybe
more? Hard to say -- it mostly depends upon how much we try to chew off in
the "next release".
> In my opinion? 1.1.beta1, 1.1.beta2, etc. When the beta period is done
>...
> (As to 1.1.0 versus 1.1 and 1.0.0 versus 1.0, I am slightly agnostic,
> though I tend to favor the 1.0.0 form because it consistently uses three
> version components.)
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.
Cheers,
-g
(*) and to that end, I dislike the tags/ directory containing a mix of 2-
and 3-number version names.
--
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
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 19:56, kfogel@collab.net wrote:
> ... but as they approach a new release, many projects *do* start
> releasing bleeding edge tarballs for testing.
Right... but the key thing is that these are testing releases in
preparation for a new stable release, and their version numbers should
reflect this. Also, we should branch for 1.1 before we start putting
out tarballs for testing for 1.1, and we should make our testing
tarballs off of the 1.1 branch, not the trunk
> But at some point, IMHO sooner rather than later, we'll want to make
> dev tarballs available again, and when we do, they'll need names.
> What should those names be?
In my opinion? 1.1.beta1, 1.1.beta2, etc. When the beta period is done
and the release is ready to unleash upon the unwashed masses, you
release 1.1.0, and when you discover the horrible security hole in 1.1.0
that you need to patch, you release 1.1.1. (This is compatible with
RPM, incidentally. 1.1.beta1 is less than 1.1.0 is less than 1.1.1.)
Why do I like this better than 1.1.1-dev, 1.1.2-dev, etc., followed
eventually by 1.2.0? Because:
* It makes it clearer that the 1.1 testing releases are associated
with the 1.1 release branch.
* It doesn't invite people to accidentally (or deliberately) drop the
-dev suffix off the version number and possibly confuse other users with
it.
* It's more elegant. All integers are created equal; there's nothing
distinguished about odd numbers in the second spot.
(As to 1.1.0 versus 1.1 and 1.0.0 versus 1.0, I am slightly agnostic,
though I tend to favor the 1.0.0 form because it consistently uses three
version components.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> I reiterate that we should consider limiting ourselves to making
> version-numbered releases on stable branches only, and not making
> "development" releases. If you look at the larger body of free software
> projects out there, most of them do not make a frequent practice of
> making development releases after they reach 1.0. The big example of a
> project which does so is the Linux kernel, which historically hasn't had
> a publically accessible repository to pull from. (And it has much less
> frequent development releases now that it does have such a repository.)
Hmmm. That's true for most projects most of the time, but as they
approach a new release, many projects *do* start releasing bleeding
edge tarballs for testing. In our case this is particularly
important, because finding bugs is so dependent on testing with a wide
variety of data and usage patterns. The developers alone could never
do it thoroughly enough; we need those adventurous users, and the
tarballs make it convenient for them to help.
I'm not sure how we'll determine when to start making those
development releases again. If you're arguing that we not start doing
it immediately, but rather only make development sources available
from the repository for a while, I could see that being a good
strategy. It certainly reduces the burden on the release manager.
But at some point, IMHO sooner rather than later, we'll want to make
dev tarballs available again, and when we do, they'll need names.
What should those names be?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 18:41, Brian W. Fitzpatrick wrote:
> OK, so how about if we stick to the even/odd convention, plus we
> include either the string 'dev' or 'unstable' in development
> releases?
Well, it's not totally anathema to me, but it strikes me as ugly and I
don't see what it buys us.
I reiterate that we should consider limiting ourselves to making
version-numbered releases on stable branches only, and not making
"development" releases. If you look at the larger body of free software
projects out there, most of them do not make a frequent practice of
making development releases after they reach 1.0. The big example of a
project which does so is the Linux kernel, which historically hasn't had
a publically accessible repository to pull from. (And it has much less
frequent development releases now that it does have such a repository.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Brian W. Fitzpatrick" <fi...@red-bean.com> writes:
> OK, so how about if we stick to the even/odd convention, plus we
> include either the string 'dev' or 'unstable' in development releases?
>
> subversion-1.1.32-dev.tar.gz
> or
> subversion-1.1.32-unstable.tar.gz
>
> as opposed to stable releases:
>
> subversion-1.0.87.tar.gz
>
> Does that seem like a reasonable compromise?
I was going to suggest just that, even going as far as teaching
dist.sh to Do The Right Thing in svn_version.h and in the name of the
tarball based on the minor version number.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Branko Čibej <br...@xbc.nu>.
Brian W. Fitzpatrick wrote:
>
> On Dec 4, 2003, at 3:58 PM, Branko Čibej wrote:
>
>> Oh, remember that we have to make the dev/release distinction on the
>> stable branch, too. So there'd be a 1.0.87-dev, which would come to life
>> as soon as 1.0.86 was released, and die with the release of 1.0.87.
>
>
> Um, this distinction is for *releases*, not branches.
There must be something in the svn_version.h on the tip of the branch
that indicates whether a release was made from a particular revision. I
expect we'll have a stable 1.0 branch and copy tags off it.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 4, 2003, at 3:58 PM, Branko Čibej wrote:
> Oh, remember that we have to make the dev/release distinction on the
> stable branch, too. So there'd be a 1.0.87-dev, which would come to
> life
> as soon as 1.0.86 was released, and die with the release of 1.0.87.
Um, this distinction is for *releases*, not branches.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Branko Čibej <br...@xbc.nu>.
Brian W. Fitzpatrick wrote:
>
> On Dec 4, 2003, at 3:22 PM, Branko Čibej wrote:
>
>> Brian W. Fitzpatrick wrote:
>>
>>> Normal users shouldn't ever even be aware of development
>>> (odd-numbered) releases--I mean, when's the last time that you went
>>> and "accidentally" grabbed a 2.5 release of the Linux kernel because
>>> you saw that 2.5.x is higher than 2.4.x?
>>
>>
>> Um. there's a world of difference between the Linux kernel and
>> Subversion. For one thing, far more people are likely to grab a new
>> Subversion release.
>
>
> OK, so how about if we stick to the even/odd convention, plus we
> include either the string 'dev' or 'unstable' in development releases?
>
> subversion-1.1.32-dev.tar.gz
> or
> subversion-1.1.32-unstable.tar.gz
>
> as opposed to stable releases:
>
> subversion-1.0.87.tar.gz
>
> Does that seem like a reasonable compromise?
It's more than a compromise, it's having *two* dev/release resolution
shcemas. :-)
Oh, remember that we have to make the dev/release distinction on the
stable branch, too. So there'd be a 1.0.87-dev, which would come to life
as soon as 1.0.86 was released, and die with the release of 1.0.87.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 4, 2003, at 3:22 PM, Branko Čibej wrote:
> Brian W. Fitzpatrick wrote:
>
>> Normal users shouldn't ever even be aware of development
>> (odd-numbered) releases--I mean, when's the last time that you went
>> and "accidentally" grabbed a 2.5 release of the Linux kernel because
>> you saw that 2.5.x is higher than 2.4.x?
>
> Um. there's a world of difference between the Linux kernel and
> Subversion. For one thing, far more people are likely to grab a new
> Subversion release.
OK, so how about if we stick to the even/odd convention, plus we
include either the string 'dev' or 'unstable' in development releases?
subversion-1.1.32-dev.tar.gz
or
subversion-1.1.32-unstable.tar.gz
as opposed to stable releases:
subversion-1.0.87.tar.gz
Does that seem like a reasonable compromise?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Branko Čibej <br...@xbc.nu>.
Brian W. Fitzpatrick wrote:
> Normal users shouldn't ever even be aware of development
> (odd-numbered) releases--I mean, when's the last time that you went
> and "accidentally" grabbed a 2.5 release of the Linux kernel because
> you saw that 2.5.x is higher than 2.4.x?
Um. there's a world of difference between the Linux kernel and
Subversion. For one thing, far more people are likely to grab a new
Subversion release.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by David Waite <ma...@akuma.org>.
Greg Hudson wrote:
>On Thu, 2003-12-04 at 18:07, Brian W. Fitzpatrick wrote:
>
>
>> And to address other issues, any package maintainer
>>worth his salt isn't going to blindly package up a dev release without
>>wrapping it in yellow-tape and concertina wire.
>>
>>
>
>This seems naive to me. People have been blindly packaging up
>Subversion 0.x releases without wrapping them in yellow-tape for years.
>Red Hat 9 includes svn 0.17 with nary a warning for the user. The fact
>that there are binary packages of svn 0.x at all vaguely horrifies me
>(except on Windows, where source distribution isn't very accessible to
>most users), but I've always figured there is nothing I can do about it.
>
>
For open-source projects, the idea of 'stable' is usually not related to
version # at all. Witness openssl 0.9.7. Until you actuall start
declaring releases stable, people will just assume everything you
publish is 'as stable as it gets'.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-04 at 18:07, Brian W. Fitzpatrick wrote:
> Normal users shouldn't ever even be aware of development (odd-numbered)
> releases--I mean, when's the last time that you went and "accidentally"
> grabbed a 2.5 release of the Linux kernel because you saw that 2.5.x is
> higher than 2.4.x?
I'm sure it happens, but probably not all that frequently since the
intersection of {users who want to muck with their kernel} and {users
who shouldn't be using odd-numbered Linux releases} is fairly small.
I have certainly accidentally grabbed about two dozen odd-numbered GNOME
package releases from their FTP site for work and wasted a day cleaning
up afterwards. That's why I hate that convention: even if you know it
exists, you also have to know which projects it applies to.
> And to address other issues, any package maintainer
> worth his salt isn't going to blindly package up a dev release without
> wrapping it in yellow-tape and concertina wire.
This seems naive to me. People have been blindly packaging up
Subversion 0.x releases without wrapping them in yellow-tape for years.
Red Hat 9 includes svn 0.17 with nary a warning for the user. The fact
that there are binary packages of svn 0.x at all vaguely horrifies me
(except on Windows, where source distribution isn't very accessible to
most users), but I've always figured there is nothing I can do about it.
But I can try to make sure that our version numbers aren't deceptive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 4, 2003, at 2:19 PM, Branko Čibej wrote:
> Greg Hudson wrote:
>
>>> This is essentially the "even==stable, odd==dev" scheme that many
>>> other projects use.
>>>
>>>
>>
>> ... which is confusing as hell to the uninitiated. -0.9 on such a
>> numbering scheme.
>>
>>
> I agree, and add my -1. There are lots of other ways to tag an unstable
> version, two of which we're acquainted with:
>
> * Apache says x.y.z-dev *before* releasing x.y.z. (This is also
> GCC's way, I believe.)
This is not the same thing as having a maintenance track and a
development track. I present the APACHE_2_1_* dev branch as exhibit
#1.
> * BDB starts with x.y.0, making patch "releases" in between, then
> declares x.y.z as stable (e.g., the stable releases were 4.0.14,
> 4.1.25 and 4.2.50 -- not 4.0.0, 4.1.0 and 4.2.0)
>
> I prefer the Apache way, which means we release 1.0.0, then bump the
> trunk to 1.1.0-dev. Patch releases from the 1.0 branch would be 1.0.x.
> We can tag 1.1 prereleases with date stamps, e.g., tags/1.1.0-20040513,
> with "svn --version --quiet" saying "1.1.0-dev"
How is this different from what Karl is proposing aside from the fact
that you're not declaring the odd/even scheme? We're talking about
making an even-numbered release, which then becomes maintenance track,
and trunk continues as (odd-numbered) dev. Once dev on trunk
stabilizes and we're ready for release, then that becomes the next even
minor number, goes into maintenance, and dev continues on the next odd
minor number. It seems really simple to me. This looks like this:
.35 -> 1.0.0 rc
1.0.0 rc -> 1.0.0 maintenance, which is re-released as 1.0.1, 1.0.2
... 1.0.147, etc.
1.1.0 is born as a dev track, which becomes 1.1.x ... 1.1.793, etc
1.1.793 -> 1.2.0 rc
1.2.x rc -> 1.2.x maintenance, which is re-released as 1.2.x ...
1.2.237, etc.
1.3.0 is born as a dev track.....
1.3.x -> 1.4.0 rc
1.4.0 rc -> 1.4.x maint
Well, I like my bikeshed the same color as Karl's, so here's my +1 for
his stated even/odd numbering scheme (which I did discuss with him
prior to his sending the initial mail).
Normal users shouldn't ever even be aware of development (odd-numbered)
releases--I mean, when's the last time that you went and "accidentally"
grabbed a 2.5 release of the Linux kernel because you saw that 2.5.x is
higher than 2.4.x? And to address other issues, any package maintainer
worth his salt isn't going to blindly package up a dev release without
wrapping it in yellow-tape and concertina wire.
-Fitz, preparing for the flames of Čibej
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>>This is essentially the "even==stable, odd==dev" scheme that many
>>other projects use.
>>
>>
>
>... which is confusing as hell to the uninitiated. -0.9 on such a
>numbering scheme.
>
>
I agree, and add my -1. There are lots of other ways to tag an unstable
version, two of which we're acquainted with:
* Apache says x.y.z-dev *before* releasing x.y.z. (This is also
GCC's way, I believe.)
* BDB starts with x.y.0, making patch "releases" in between, then
declares x.y.z as stable (e.g., the stable releases were 4.0.14,
4.1.25 and 4.2.50 -- not 4.0.0, 4.1.0 and 4.2.0)
I prefer the Apache way, which means we release 1.0.0, then bump the
trunk to 1.1.0-dev. Patch releases from the 1.0 branch would be 1.0.x.
We can tag 1.1 prereleases with date stamps, e.g., tags/1.1.0-20040513,
with "svn --version --quiet" saying "1.1.0-dev"
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.35 => Beta => 1.0 schedule
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-12-03 at 23:10, kfogel@collab.net wrote:
> At that point, I think we're ready to enter Beta. Here's a plan,
> comments welcome of course.
In http://www.contactor.se/~dast/svn/archive-2003-10/0128.shtml
you proposed the same plan, but later appeared to concede that you were
happy to stabilize on the trunk. I continue to favor stabilizing on the
trunk; otherwise, we run the risk of having a long beta period where the
stable branch diverges dramatically from the trunk, and our resources
are divided between them.
> This is essentially the "even==stable, odd==dev" scheme that many
> other projects use.
... which is confusing as hell to the uninitiated. -0.9 on such a
numbering scheme.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org