I'm partial to 2.0.0-alpha[x]/beta[x]
* Conveys that it's 2.x (not 1.x)
* Conveys "instability"
* Doesn't buck Maven's view of the world (Maven is happy with a version
string of 2.0.0-alpha)
* Still enables a "2.0.0" later
Sean Busbey 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?
