*> 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?*
Yes, and they do (Spring Boot is a prime example). Many (many) users, even potential customers, use these artifacts for POCs/prototypical purposes and planning around future releases/development (depending on a much needed feature). EA of OSS is the cornerstone for success in OS IMO. As such, Milestones and RCs are an important vehicle for driving early feedback and adoption, along with managing scope and prioritizing the most important UCs to our users (first) before the final RELEASE becomes generally available (GA). Thanks, John On Wed, Jan 13, 2016 at 5:14 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > 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) > -- -John 503-504-8657 john.blum10101 (skype)
