On Nov 28, 2005, at 8:07 PM, Justin Erenkrantz wrote:
On Mon, Nov 28, 2005 at 07:54:24PM -0800, Roy Fielding wrote:
What rules are you talking about? GA just means it isn't alpha or
beta -- it
has nothing whatsoever to do with the version number. 2.2 is now our
STABLE
branch, not our GA branch.
See VERSIONING.
I've seen it. 2.2.0 is our stable branch. I believe the vote
indicates that
the 2.2.0 release should match the code in 2.1.10 modulo the changes
necessary
to bump the version and update the documentation. However, nobody
bypasses
our release voting procedure just because they committed some
document in CVS.
Release votes are on completed, verifiable, signed source tar balls.
What documentation are you talking about?
ABOUT_APACHE
CHANGES
docs/manual/*
INSTALL
LAYOUT
README
*/*/README
include/ap_release.h
include/ap_mmn.h (probably okay as is)
and that is just what goes inside the tarball. We also have to
update the
STATUS files, the website (I see Paul has started that), create
docs-2.2,
and all of the other things people will remember as soon as we cross the
tarball threshold.
I mentioned those on our trip to Wells Fargo last week. I would have
fixed
them myself by now, but I made the mistake of updating my OS X 10.3.9 to
10.4.3 and Xcode 2.2 first, which led to three wasted days trying to fix
lame fink bugs instead.
In any case, we vote on complete source tarballs, not some
expectation of
a tag. There can't be any 2.2.0 release votes yet because it doesn't
exist
as a released tarball, nor can it exist until we have updated the
docs.
Yes, and we voted on the tarball contents which would be identical to
2.1.10. The only change is the release number inside ap_release.h.
I don't consider that a material change that would alter my vote.
So if I were to go the website and cp 2.1.10.tar* 2.2.0.tar* you
wouldn't change your vote on that copy? You wouldn't mind that the
tarball has ap_version wrong, the docs were last updated in 2002,
and we would need to do a 2.2.1 to clean that trivial stuff up?
I am not asking you to change your vote once a 2.2.0 tarball is created.
I am telling you that you can't vote on 2.2.0 until a tarball is created
that calls itself 2.2.0 and thus is available for review. I refuse to
believe that anyone on the PMC has reviewed a release package that
hasn't
even been packaged yet.
Feel free to veto any technical change that would cause 2.2.0 to differ
significantly from 2.1.10. Feel free to make your vote on 2.2.0 on the
basis of a recursive diff between the two tarball packages.
The majority of votes cast were for GA. At least to me and Rich (and
likely others), that implied 2.2.0. A few people (but not enough to
alter the majority) specifically said that they would not vote for
2.2.0. -- justin
The only vote I saw was a 2.1.10 release vote and a statement of
intention
to make 2.2.0 match the code in 2.1.10. That does not imply 2.2.0 is
being
released based on that vote, which is patently absurd. If you think
anything
in our guidelines implies such a thing, then please point it out so that
I can delete it.
....Roy
