I don’t like the rc1-rc1 bit. I think once one knows the reason it exists, they can understand it, but a release candidate for a release candidate, is just hard to say with a straight face IMO. I prefer the rc1-vc1 bit myself. Either way, I think folks will ask what it means, but at least the words for the shorthand match exactly what it is; voting candidate for a release candidate versus RC for an RC. My couple pennies.
Wade > On May 29, 2018, at 4:15 PM, Antonio <[email protected]> wrote: > > 0 > > I don't see a problem with the "rc1-rc1", "rc1-rc2" approach. > > Cheers, > Antonio > > On 29/05/18 22:03, Geertjan Wielenga wrote: >> We’re going to continue to use the release90 branch. >> The next — and hopefully last — release candidate before the final release >> of NB 9.0 will be rc2. >> We will need to vote on that release in the Apache PPMC and IPMC just like >> all other releases. >> There may be a need to vote multiple times, though we’re getting better at >> putting releases together and so, just like for the rc1, we may only need >> one round of votes. >> Anyway, I propose we use the shortened names rc2-vc1, rc2-vc2, rc2-vc3, >> i.e., ‘vc’ standing for ‘voting candidate’, these would be for an assumed >> three rounds of Apache voting for the rc2 release, though we’ll probably >> only need rc2-vc1. >> That is also the structure suggested by our mentor Bertrand. >> The rc2 will be the releae on which the NetCAT and beyond Community >> Acceptance survey will be done. >> Unless there are objections, I propose we use this structure. If you >> object, you should provide a counter proposal. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
