On 2/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 2/23/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > Personally, I think it gets silly to have to vote each time.
The danger of a bombastic statement; everyone includes that one line
in their replies and not the "however here's why we should" bit
afterwards :)
> Well, we really shouldn't cast a binding vote on a release until we
> put into production ourselves. ("Eat our own dog food.") Since this is
> a new roll, we have to unroll it, put it up, and run the binary
> through its paces. just to be certain all the bits are there.
Biggest problem I find with that is that it means following tests
aren't possible.
If I migrated production from 2.0 to 2.1-rc1; my next install is
2.1-rc1 to 2.1-rc2 and not 2.0 to 2.1-rc2 at the database level. So I
just run a test server until the real one is released.
Dave, Elias and others work more at the bleeding edge; but that means
their production servers tend to be on 2.1-pre-rc1 and that migration
tends to kick off the release discussions. Unsure where Matt
(JavaLobby) fits in on things release-wise.
> After doing that, voting is the least of it :)
>
> One way to streamline the process is to using numbered milestones
> rather than beta's and RCs. Under this scheme, this distribution would
> be Roller 2.1.4. We start by releasing it as an Alpha, and then decide
> to vote it up to a Beta or GA.
>
> The benefit is that we don't have to touch the distribution pr
> repository, even just to rename things. We can tag the repository once
> as _2_1_4 and roll that milestone once and for all. If it doesn't make
> the grade, we just go onto the next milestone. Right now, if we decide
> RC5 is ready for primetime, the same set of bits might have two names
> "RC5" and "2.1".
>
> Another benefit is that we can also downgrade a release. If we later
> find a security issue, we can bring out a new milestone and change the
> quality of "2.1.4" to beta.
>
> This is the scheme that Apache HTTP, Tomcat, Struts, and others use.
Downside is that it creates unreleased versions. It really should be a
4 digit version at that point, as what you're describing is:
<major>.<minor>.<build number>
as opposed to:
<major>.<minor>.<bugfix>
Said projects are overloading their bugfix and build numbers.
Not that I'm -1; the build-admin in me thinks it should go further,
the realist thinks it's unlikely I'll have time to do what I think
should be done anytime soon.
> Incidentally, it's a good practice to record every PMC vote in a
> STATUS file. Here's the one we use with iBATIS.
>
> * http://svn.apache.org/repos/asf/ibatis/trunk/STATUS.txt
I presume that's every PMC vote that was on a public list? Rather than
every PMC vote? Seems that it would largely be a history of release
discussions.
What are advantages are you finding of recording that? Again,
nitpicking rather than being against the idea, seems better just to
put in a link to the RESULT email in mail-archives. Only one I can
think of is that it helps to maintain the dynamic charter of a project
- as with all docs, the real charter gets set in stone and becomes
untouchable.
Again, apologies if a disjoint reply - need to sleep and catch a plane
hideously early tomorrow morning,
Hen
