not sure it’s been 100% obvious, but for it to be ...
# announce
w
not sure it’s been 100% obvious, but for it to be maximally useful, i think that the alpha will need to be a “stable” release
in the sense of cherrypicks only
cutting from master each time like a
dev
release would pull in too much i think.
if it turns out that too much stuff is getting picked in and its getting challenging, we could reserve the right to do a
2.0.0.beta
too before rcs
h
I don’t think necessarily. Afaict the idea of
alpha
is that this is still not stable: all our efforts are going into improving this. But most the main new features we want are landed I suppose we could make that differentiation. Big new features shouldn’t go into the 2.0 branch anymore?
w
right. i think the choice is about “how much time are we going to be spending focused on the alpha vs everything else”. if basically everything will get cherry-picked to the alpha, then maybe not worth it.
but the flip side is: we have already had some folks use dev recently, so we can choose to cut the alpha when things are already looking relatively stable
it’s possible that we can do this lazily… basically, bump to
alpha
on master, see how many bugs get reported against it, and then branch from alpha to cherrypick if we want to
👍 1
cc @happy-kitchen-89482: ^
h
Doing this lazily sounds OK to me