I would automatically -1 any release with a number like 1.99 regardless of content.
Semantic versioning which we are following already provides an answer for this: http://semver.org/#spec-item-9 >From my experience as RM for 0.99.x series and 1.0.x series, I would suggest we do 2.0.0-alpha1 and alpha2, and one or two betas. I think we should start the alpha1 release now which does not have to wait for anything but packaging work. Enis On Tue, Mar 28, 2017 at 1:19 PM, Sean Busbey <bus...@apache.org> wrote: > Hi folks! > > What are folks opinions on how we name releases leading up to HBase > 2.0 that aren't quite done yet? > > For 1.0, we used 0.99 as a placeholder for "what we expect will be in > 1.0 but is not yet ready for production use." That got us 0.99.0, > 0.99.1, and 0.99.2 before we declared 1.0.0 ready for use. For 2.0, > continuing this pattern would be done with 1.99, I suppose. > > This issue I take with this approach is that back before 1.0, we could > count on users thinking of 0.99 as a different major release train > than 0.98. Now, I'm concerned that some might lump 1.99 in with the > 1.y major release series. > > Alternatively we could expressly label the releases as alpha/beta > based on our confidence. This would give us 2.0.0-alpha1, > 2.0.0-alpha2, etc, 2.0.0-beta1, etc. This has the disadvantage of > futzing with sort order, but clearly conveys that these releases are > both part of what will be the 2.y major release series and not for the > faint of heart. > > > Thoughts? >
