I think Karthik correctly identified the two reasons we might want to
denote a release as "unstable":
a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what "alpha" typically means.
b) Quality. As Konst says, a release can be allowed to break compatib
There are a couple of different approaches we could take.
How about publishing/releasing bits such as “2.8.0-RC0”. Downstream projects
can depend on these and use them normally similar to the approach that they
would have taken with release 2.8.0 or 2.8.0-alpha. After some baking ( or more
RC
I don't think it makes sense to imprint the release quality with its
version.
They should be separate. And our recommendation for the quality can be
reflected in the documentation.
(1) is the way to go.
We had "alpha" imprinted in 2.0.5-alpha version, but both 2.0.5 and 2.0.6
releases were quite s
Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.
I would use approach (2) for compatibility concern
Thanks for forking this Vinod,
Linux used to do the odd/even minor versions for unstable/stable, but that
went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
always stable. The odd/even though was at least a convention everyone knew
about.
Stack can comment better than I abo
Forking the thread.
In the previous 2.7.1 thread [1], there were enough yays to my proposal to wait
for a bug-fix release or two before calling a 2.x release stable. There were
some concerns about the naming.
We have two options, taking 2.8 as an example
(1) Release 2.8.0, call it as an alpha
