On 3/14/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
Henning Schmiedehausen wrote:
> You actually have to roll and sign a tarball/zip ball on which the vote > happens. "Release-then-Vote" seems to be the only accepted way by the > board these days; Thankfully, neither events in velocity-private nor board feelings apply here. Either Jakarta PMC votes for it or receives an resolution, before that happens, existing procedures [1] stay.
There are (to my knowledge) three types of vote/release styles that have been happening at the ASF. 1) A vote to do a release, with no sign of release files. This is how this thread started and it's against ASF policy. 2) A vote on release-candidate files (or -dev in your case), and then a release that is trusted to be a repeat of the process used. This is currently a grey area policy-wise, and is where this release moved to with the ~/vgritsenko/*-dev files. 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet.
> personally I do prefer "Vote-then-Release" myself but > that seems to be the way it is.
Release-then-Vote has some nice parts, the actual release is really easy. That's nice if the release process has been painful as it means I don't have to remember how to do the damn thing. Vote-then-Release is nice in that you don't end up doing as many vote builds. Other parts of the ASF seem to do a release where they make a build and if it passes a vote it goes out, if it doesn't then they up the bugfix number and do it again (I don't think anyone actually has a build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that the version number doesn't show. Very confusing as a user I think. Mostly at this stage the mandate is that we have to be voting on release files, not on "Hey, how about a release". Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
