You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by qu...@apache.org on 2005/05/03 00:30:37 UTC
svn commit: r165704 - /spamassassin/trunk/build/README
Author: quinlan
Date: Mon May 2 15:30:35 2005
New Revision: 165704
URL: http://svn.apache.org/viewcvs?rev=165704&view=rev
Log:
move the point of return to be a bit earlier
Modified:
spamassassin/trunk/build/README
Modified: spamassassin/trunk/build/README
URL: http://svn.apache.org/viewcvs/spamassassin/trunk/build/README?rev=165704&r1=165703&r2=165704&view=diff
==============================================================================
--- spamassassin/trunk/build/README (original)
+++ spamassassin/trunk/build/README Mon May 2 15:30:35 2005
@@ -127,6 +127,11 @@
svn commit -m "X.Y.Z RELEASED"
+ this is the point of no-return, once this commit has been made, the
+ version number is considered "burned". Even if the release is not
+ made at this point, the number is locked for this particular code.
+ The same number cannot be used for a future different release.
+
- Now, start the new development codebase. For minor updates of a 2.x
tree (e.g. 2.x1, 2.x2), you don't need to branch; for major updates
(2.x0) you should use a new development branch, off the trunk.
@@ -148,11 +153,6 @@
svn commit -m "X.Y.N devel cycle started"
(where X.Y.N is the new version number)
-
- this is the point of no-return, once this commit has been made, the
- version number is considered "burned". Even if the release is not
- made at this point, the number is locked for this particular code.
- The same number cannot be used for a future different release.
- (for any rc, prerelease, or full release) Place the tarballs in a
private location and request a vote on dev@spamassassin.apache.org to
Re: svn commit: r165704 - /spamassassin/trunk/build/README
Posted by Daniel Quinlan <qu...@pathname.com>.
Michael Parker <pa...@pobox.com> writes:
> Respectfully disagree. Once a release has been rolled, heck once
> we've checked in the uncommented IS_DEV_BUILD SpamAssassin.pm and
> Changes file, then it's out there and effectly released and
> available. If you come back later and update a file or make a change
> and re-release you'll never know if someone has the old release or the
> new one.
I think there is something to this point of view, but it's not so bad to
start over if we haven't made tarballs.
> Version numbers are cheap, might as well use them. We're an open
> source project, we should be releasing more often and earlier.
> Setting things up so that anyone can declare a proper time to release
> and then going off and doing it helps with that policy. If a release
> has a problem, you scrap it and move onto the next.
I agree that they are cheap. We've had the three +1 policy for a while,
nothing new with that. I'm just hoping to answer this sort of question
*before* it comes up and we're all stressed out about it. I can go
either way at this point.
> It's a widely accepted practice for other Apache project, such as APR
> and Httpd. I really wish I could find the original thread when Greg
> Stein proposed it, it was really well thought out and put things in
> the right perspective.
That might be good to see.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: svn commit: r165704 - /spamassassin/trunk/build/README
Posted by Michael Parker <pa...@pobox.com>.
On Mon, May 02, 2005 at 03:58:20PM -0700, Justin Mason wrote:
>
> OK, I do not agree with this. in my opinion, a release number is only
> "burned in stone" once the file is announced, uploaded to CPAN, etc.
> I'd prefer to avoid "burning" too early, as it makes for less flexibility.
>
> What if a bug is found in those prerelease tarballs? We move onto
> 3.0.(x+1) without issuing 3.0.x, immediately? That's (a) messy, (b) ugly,
> (c) will cause confusion among users and packagers, and (d) is
> unprecedented either in *this project*, or others.
Respectfully disagree. Once a release has been rolled, heck once
we've checked in the uncommented IS_DEV_BUILD SpamAssassin.pm and
Changes file, then it's out there and effectly released and
available. If you come back later and update a file or make a change
and re-release you'll never know if someone has the old release or the
new one.
Version numbers are cheap, might as well use them. We're an open
source project, we should be releasing more often and earlier.
Setting things up so that anyone can declare a proper time to release
and then going off and doing it helps with that policy. If a release
has a problem, you scrap it and move onto the next.
It's a widely accepted practice for other Apache project, such as APR
and Httpd. I really wish I could find the original thread when Greg
Stein proposed it, it was really well thought out and put things in
the right perspective.
Why should we be afraid to skip a release? Folks only care what the
latest is, not that they missed one.
> Let's not make rules for the sake of making rules!
Like I said, several other Apache projects follow the same release
guidelines.
Michael
Re: svn commit: r165704 - /spamassassin/trunk/build/README
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, May 02, 2005 at 03:58:20PM -0700, Justin Mason wrote:
> OK, I do not agree with this. in my opinion, a release number is only
> "burned in stone" once the file is announced, uploaded to CPAN, etc.
> I'd prefer to avoid "burning" too early, as it makes for less flexibility.
+1
> What if a bug is found in those prerelease tarballs? We move onto
> 3.0.(x+1) without issuing 3.0.x, immediately? That's (a) messy, (b) ugly,
> (c) will cause confusion among users and packagers, and (d) is
> unprecedented either in *this project*, or others.
It's not unprecedented, I've seen it done before even w/ things like
httpd iirc. I really don't like it when it happens though.
--
Randomly Generated Tagline:
Love isn't hopeless. Look, maybe I'm no expert on the subject, but there
was one time I got it right.
-- Homer Simpson
Another Simpson's Clip Show