I think you nailed it! ASF has a very simple rule (and this is one of the few times where it IS a process rule -- there's no way around it whether you like it or not). Here's the rule: anything that gets disclosed to the general public needs to be voted by a PMC as a formal release. That's it.
So I think the real question to ask of Spring folks is this: do they expect Mx and RCx artifacts to be consumed by general public? Thanks, Roman. On Wed, Jan 13, 2016 at 1:23 PM, John Blum <jb...@pivotal.io> wrote: > Hmm, interesting. I guess the main difference is in how we are defining a > "release candidate". > > With Apache, it would seem release candidates are used to start a process > to determine whether a project at it's current version (e.g. 1.0.0.M1) is > in a releasable state, as voted on by the PMC. Hence, the distinction > being a candidate for release rather than an explicit version qualifier. > > With Spring, while Milestones (Mx) and explicit RC (RCx) qualified version > are released, they are not "official" releases, as I have just learnt. This > means, we do not officially make Milestones and RCx (versions) available in > Maven Central, only in Spring artifact server. Once the > major.minor.patch.RCx based version(s) reach a relatively quite period in > terms of issue feedback, the team then decides to make an "official" > release (1.0.0.RELEASE) that is pushed to Central. > > Not sure if that changes the perspective on things, but wanted to make sure > that was clear. > > Thanks, > John > > > On Wed, Jan 13, 2016 at 12:40 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > >> On Wed, Jan 13, 2016 at 12:18 PM, Justin Erenkrantz >> <jus...@erenkrantz.com> wrote: >> > Even if the release fails the vote, you shouldn't be reusing that >> > version again. >> >> And that's where the current suggested mode becomes super confusing >> *unless* we all agree not to use RC designation. >> >> Here's a scenario that is very likely to happen: >> 1. An actual release with a version string 1.0.0-incubating.RC1 is >> put up for a vote. Lets call it artifact #1 >> 2. The vote fails. >> 3. You create artifact #2 with exactly the same version string >> 1.0.0-incubating.RC1 to take care of the issues that made >> the vote fail >> >> How do you avoid confusion between referring to #1 vs. #2 ? In 99% >> of asf projects you'd call #1 an RC1 and #2 RC2. But then of course >> you're talking 1.0.0-incubating.RC1 RC2 -- if that's not confusing I don't >> know what is. So that's no good at all. >> >> Alternatively (and that's how Apache Subversion does it as community, >> not as a source code management tool) you could skip #s if the vote >> fails. So once #2 happens you will produce 1.0.0-incubating.RC2 without >> every using 1.0.0-incubating.RC1 ever again. I suppose that this could >> work, but lets be absolutely clear about the steps then. >> >> IOW, if the following statement captures what Geode community *really* >> wants to do -- I have nothing against it (aside from the fact that you'd >> be different from 99% of projects I know in ASF). >> >> Here's the statement: every single time a vote fails on MX or RCX artifact >> you proceed to vote on M(X+1) or RC(X+1) without *ever* re-using >> MX or RCX version IDs. IN ADDITION, when you're ready to produce >> .RELEASE release you simply re-use the last RCZ version and call >> it a RELEASE. IOW, the vote on a RELEASE never really happens. The >> vote always happens on RCZ and then the community declares it to >> be a release. >> >> Phew. That was a pretty convoluted statement, but if you really want >> the above to be your release policy -- sure. >> >> Thanks, >> Roman. >> > > > > -- > -John > 503-504-8657 > john.blum10101 (skype)
