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 2004/01/26 16:59:52 UTC
1.0.0, 1.0.x plan
This is the first of two mails. This one deals with how to treat the
0.37/1.0 line between now and the 1.0.0 release, and how to treat the
1.0.x line after that release.
The second mail will be about the larger Post-1.0 universe -- about
achieving consensus on what should go into 1.x versus 2.0. (The
second mail will also talk about release numbering, but I need to go
carefully back over our long thread on that before making a serious
proposal.)
Needless to say, this first mail is the simpler of the two :-).
Everything below is merely one proposal, just how I envision the
process working. Although written in declarative tone for clarity,
I'm not trying to present it as the only possible path. Feedback
(negative or positive) is welcome.
Release 0.37.0 is our first "1.0 candidate" release, meaning that
barring the discovery of serious bugs, it is what we will release as
1.0. We should aim to have four weeks of "soak time" for this code,
so we can be confident it contains no surprises.
Note that I said "surprises", not "bugs" :-). We should assume we'll
find *some* bugs in 0.37.0, the question is only how serious will they
be. We should evaluate them on a case-by-case basis. If a bug is
deemed acceptable for the 1.0 release (and I expect/hope most will
be), we can treat it like any other bug: file an issue, maybe fix it
in trunk right then if we want.
Of course, there will be some fixes that we feel should eventually get
into the 1.0.x line, just not into 1.0.0. (I'm punting on the release
numbering question for the moment -- for the sake of discussion, let's
talk as though "1.0.0", "1.0.1", and "1.0.2", are successive public
releases on the stable 1.0 line.) To keep track of such changes,
let's use the STATUS file as before. Since 1.0.x is supposed to be a
stable, ABI-compatible line, let's also use the same voting system
there, for as long as the line lasts.
However, for a clear lineage from 0.37.0->1.0, what I'd like to do is:
1. Remove the 1.0-stabilization branch, which has had no changes
since r8509, when josander branched 0.37.0.
2. Create branches/1.0.0, copied from the 0.37.0 tag.
3. Accept certain kinds of innocuous commits in the 1.0.0 branch for
the next four weeks [details below], including STATUS commits.
An "innocuous commit" is one that doesn't affect our four-week
soak time.
4. When Feb. 23rd arrives, josander rolls subversion-1.0.0.tar.gz
from the 1.0.0 branch, tags it, and goes contentedly to bed :-).
Obviously, no core code change is innocuous. But these kinds of
changes are:
* Any documentation changes, including book changes, INSTALL,
HACKING, www/ area, etc. (The www/ area we can just update all
at once from trunk on the day of the release, if we want.)
* Any dist.sh changes josander wants.
* STATUS file updates, such as inserting 1.0.1 candidate changes.
I think the above categories don't even need voting, let's just treat
them like trunk commits, with post-facto review. Meanwhile, the
categories below would use the voting system, but still not affect the
soak time:
* Anything in tools/, packages/.
* Bindings-only changes. (I'm hoping there aren't any more 1.0
bindings changes left, but if there are, it's more important to
ship with the latest bindings than to soak the bindings for a
whole month.)
* Doc fixes in core code header files or source files.
If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
per usual procedures, then run the above algorithm with "0.37.1"
substituted for "0.37.0". In which case, the four-week countdown
would start from 0.37.1's release date, not 0.37.0's, of course.
That's all. Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >So let's branch from the 0.37.0 tag and make a new STATUS file so I can
> >write an item there as soon as possible (I do even have more changes to
> >do there before 1.0).
>
> I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
Just so you're both aware:
There are *no* changes in 0.37.0 from 1.0-stabilization. Therefore,
now that 1.0-stabilization has been renamed to 1.0.x, there is no need
to merge anything over from 0.37.0. We're completely up-to-date.
(I don't think Josander necessarily disagrees with you, Brane, I think
he just responded to my mail before seeing your followup suggestion.)
> I really don't know why this is necessary. All necessary changes to
> installers should be made on the release branch before the release is
> tagged, otherwise people can't make their own packages from the tarball.
Agree. What we should be doing from now on, in general, is:
Make changes in branches/1.0.x/. When ready, snap a tarball from it.
Never create another branch for it, but when the tarball is released,
do 'svn cp -r XXX branches/1.0.x tags/1.0.1' (or whatever), where XXX
is the revision used for the tarball.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 27 January 2004 20.27, Branko Čibej wrote:
> Jostein Chr. Andersen wrote:
> >The packages too? I have used the installer source from the trunk all
> > the time (while the branched code have been older and older).
> >
> >The only win32 installer code that works is that one in the trunk
> > (it's even the most stable installer so far :-).
>
> This is not a good situation. IMHO the installer on the branch should
> be kept up-to-date -- remember, Win32 build on the trunk is already
> significantly different than the one on the branch (trunk uses APR
> DLLs)
I have been asking about how to handle this both on IRC and several times
on the dev list without getting any response, thanks :-)
So let's branch from the 0.37.0 tag and make a new STATUS file so I
> > can write an item there as soon as possible (I do even have more
> > changes to do there before 1.0).
>
> I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
The inno setup in tags/0.37.0 are outdated, the inno setup in the trunk
are a perfect match for 0.37.0 and (have you noticed: -Not a single
problem or complain about the Windows installer this time? :-)
> >Please, remember that packages/installers are made _after_ the
> > tarball. Changes in this might occure after a release tag.
>
> I really don't know why this is necessary. All necessary changes to
> installers should be made on the release branch before the release is
> tagged, otherwise people can't make their own packages from the
> tarball. That's weird
In my case, the Windows installer are made after you have made the
binaries. Hopefully, some bindings will come on regular basis (jave,
perl)as well so I can make a full Installer as well.
The thing is that I really don't know what to include in the installer
every time it's created.
> We can do this at least for Windows, where the package maintainer and
> release manager are the same person. :-)
Me to (RM have a multi personality... ..oh, so do I, cool! ;-)
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
Jostein Chr. Andersen wrote:
>On Monday 26 January 2004 17.59, kfogel@collab.net wrote:
>
>
>>I think the above categories don't even need voting, let's just treat
>>them like trunk commits, with post-facto review. Meanwhile, the
>>categories below would use the voting system, but still not affect the
>>soak time:
>>
>> * Anything in tools/, packages/.
>>
>>
>
>The packages too? I have used the installer source from the trunk all the
>time (while the branched code have been older and older).
>
>The only win32 installer code that works is that one in the trunk (it's
>even the most stable installer so far :-).
>
>
This is not a good situation. IMHO the installer on the branch should be
kept up-to-date -- remember, Win32 build on the trunk is already
significantly different than the one on the branch (trunk uses APR DLLs)
>So let's branch from the 0.37.0 tag and make a new STATUS file so I can
>write an item there as soon as possible (I do even have more changes to
>do there before 1.0).
>
>
I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
>Please, remember that packages/installers are made _after_ the tarball.
>Changes in this might occure after a release tag.
>
>
I really don't know why this is necessary. All necessary changes to
installers should be made on the release branch before the release is
tagged, otherwise people can't make their own packages from the tarball.
That's weird.
We can do this at least for Windows, where the package maintainer and
release manager are the same person. :-)
--
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: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2004-01-27 at 11:14, kfogel@collab.net wrote:
> > I think we should worry more about the real consequences of the bug,
> > and trust BugTraq's readership to do the same. [Also, we should mail
> > BugTraq ourselves with a description, and a prediction of a fix in
> > 1.0.1 or whenever we schedule it for. Better to be in control of your
> > own bad news than let someone drive it :-) ]
>
> I don't really agree; just because someone on bugtraq thinks a path leak
> is a real security hole doesn't make it true. (Not saying we shouldn't
> fix it, just that we shouldn't pollute bugtraq with unimportant
> revelations.)
If someone else does post this to BugTraq, is there a mechanism by
which we can follow up with an addendum?
What I want to avoid is someone making the bug sound more serious than
it is. As long as there's a way for us to correct any misimpressions,
then I'm happy with doing nothing until if/when we see a first post.
(Of course, agree we should fix it in trunk and 1.0.1.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
Branko Čibej writes:
> I'd suggest simply renaming branches/1.0-stabilization to
> branches/1.0.x. The 1.0 series releases shoudl be made straight off this
> branch, since it should always remain stable.
Excellent suggestion. I'll do that instead, and...
> (IMHO it was a mistake to create a 0.37.0 branch, but that's counting
> birds flown. Obviously any changes that were made on 0.37.0 should be
> merged back to 1.0-stabilization.)
... also this :-). (Will doc this all up, too, so we remember.)
> We should define what "showstopper" means, and be very strict about it.
> IMHO crashes and data corruption bugs would be the only candidates at
> this point.
Let's use that as a guideline. I don't think we can predict all
possible showstoppers in advance. If someone discovers a bug that is
not a crash or a corruption problem, yet nevertheless is so serious
that everyone agrees it should hold up the release, we're not going to
tolerate it just because it didn't meet the official definition. So
yes, let's say that crashes and data corruption are the threshold of
seriousness, but also be open to judgement calls.
(If by some freak of fate we can't consense on whether a bug is
tolerable, then a vote among the full committers is the last resort,
as always. I really don't expect this to happen, though.)
Mike Mason and Mark Benedetto King wrote:
> [about a path-leakage security buglet]
This is only an information-leakage bug, a lesser class of security
bug than (say) root exploit or httpd-user exploits. While it should
be fixed in 1.0.1 or so, it's not worth holding up 1.0.0 for IMHO.
Mike mentioned BugTraq:
> There was some discussion about the importance of applying an
> information-leak fix before 1.0, because otherwise it'd come out on
> BugTraq and tarnish Subversion's reputation. I'm not sure if the fix
> got applied or not.
I think we should worry more about the real consequences of the bug,
and trust BugTraq's readership to do the same. [Also, we should mail
BugTraq ourselves with a description, and a prediction of a fix in
1.0.1 or whenever we schedule it for. Better to be in control of your
own bad news than let someone drive it :-) ]
Not saying reputation isn't important, just that this very minor
tarnishing isn't going to be a huge blow for Subversion.
I'll take Brane's suggestion and create the 1.0.x branch right now, so
we can start proposing >=1.0.1 bug fixes in STATUS right now (also,
Josander wanted to be able to start making dist changes in that line
soon).
I think that answers everything that's come up in this thread. If
anyone has any concerns not yet addressed, please make a noise :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Monday 26 January 2004 17.59, kfogel@collab.net wrote:
> I think the above categories don't even need voting, let's just treat
> them like trunk commits, with post-facto review. Meanwhile, the
> categories below would use the voting system, but still not affect the
> soak time:
>
> * Anything in tools/, packages/.
The packages too? I have used the installer source from the trunk all the
time (while the branched code have been older and older).
The only win32 installer code that works is that one in the trunk (it's
even the most stable installer so far :-).
So let's branch from the 0.37.0 tag and make a new STATUS file so I can
write an item there as soon as possible (I do even have more changes to
do there before 1.0).
Please, remember that packages/installers are made _after_ the tarball.
Changes in this might occure after a release tag.
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Jan 27, 2004 at 09:40:36AM +0000, Mike Mason wrote:
> Branko ??ibej wrote:
>
> >We should define what "showstopper" means, and be very strict about it.
> >
> >IMHO crashes and data corruption bugs would be the only candidates at
> >this point.
> >
> >
>
> How about security bugs? There was some discussion about the importance
> of applying an information-leak fix before 1.0, because otherwise it'd
> come out on BugTraq and tarnish Subversion's reputation. I'm not sure if
> the fix got applied or not.
I would like to see this fixed before 1.0, but I'm not in a position to
provide a patch right now.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Mike Mason <mg...@thoughtworks.net>.
Branko Čibej wrote:
> We should define what "showstopper" means, and be very strict about it.
>
>IMHO crashes and data corruption bugs would be the only candidates at
>this point.
>
>
How about security bugs? There was some discussion about the importance
of applying an information-leak fix before 1.0, because otherwise it'd
come out on BugTraq and tarnish Subversion's reputation. I'm not sure if
the fix got applied or not.
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>kfogel@collab.net wrote:
>
>
>>If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
>>per usual procedures, then run the above algorithm with "0.37.1"
>>substituted for "0.37.0". In which case, the four-week countdown
>>would start from 0.37.1's release date, not 0.37.0's, of course.
>>
>>That's all. Thoughts?
>>
>>
>>
>>
>We should define what "showstopper" means, and be very strict about it.
>IMHO crashes and data corruption bugs would be the only candidates at
>this point.
>
>
Just to be clear, I mean server crashes or client crashes without a
workaround. I don't think a crash in an edge case in some obscure
feature should hold up the 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: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>However, for a clear lineage from 0.37.0->1.0, what I'd like to do is:
>
> 1. Remove the 1.0-stabilization branch, which has had no changes
> since r8509, when josander branched 0.37.0.
>
> 2. Create branches/1.0.0, copied from the 0.37.0 tag.
>
>
I'd suggest simply renaming branches/1.0-stabilization to
branches/1.0.x. The 1.0 series releases shoudl be made straight off this
branch, since it should always remain stable.
(IMHO it was a mistake to create a 0.37.0 branch, but that's counting
birds flown. Obviously any changes that were made on 0.37.0 should be
merged back to 1.0-stabilization.)
[...]
>If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
>per usual procedures, then run the above algorithm with "0.37.1"
>substituted for "0.37.0". In which case, the four-week countdown
>would start from 0.37.1's release date, not 0.37.0's, of course.
>
>That's all. Thoughts?
>
>
We should define what "showstopper" means, and be very strict about it.
IMHO crashes and data corruption bugs would be the only candidates at
this point.
--
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