I think what I'd be concerned about WRT time-based releases is the
burden on RM to keep the branch in a good state. Perhaps we need to not
push that onto an RM and do better about sharing that load (looking in
the mirror).
However, I do like time-based releases as a means to avoid "hurt
feelings" (e.g. the personal ties of a developer to a feature. "The
release goes out on zzzz/yy/xx, this feature is not yet ready, can go
out one month later.." etc)
On 11/7/18 2:31 PM, Sean Busbey wrote:
Hi folks!
Some time ago we talked about trying to get back on track for a more
regular cadence of minor releases rather than maintenance releases
(like how we did back pre-1.0). That never quite worked out for the
HBase 1.y line, but is still something we could make happen for HBase
2.
We're coming up on 4 months since the 2.1 release line started. ATM
there are 63 issues in JIRA that claim to be in 2.2.0 and not in any
2.1.z version[1].
The main argument against starting to do a 2.2.0 release is that
nothing springs out of that list as a "feature" that would entice
users to upgrade. Waiting for these kinds of selling points to drive a
release is commonly referred to as "feature based releases." I think
it would be fair to characterize the HBase 2.0 release as feature
based centered on AMv2.
An alternative to feature based releases is date based releases where
we decide that e.g. we'll have a minor release each month regardless
of how much is included in it. This is sometimes also called "train
releases" as an analogy to how trains leave a station on a set
schedule without regard to which individual passengers are ready. Just
as you'd catch the next scheduled train if you miss-timed your
arrival, fixes or features that aren't ready just go in the next
regular release.
Personally, I really like the idea of doing date based releases for
minor releases with maintenance releases essentially only happening on
whatever our "stable" designator points at. It would mean those who
don't want the risk and benefits of our current release-ready work
could stay on a defined path while we could move away from maintaining
a ton of branches, some of which don't even see releases (currently ~3
that are > 3 months since a release). If some folks had a specific
need for a different minor release line and were willing to do the
backport and RM work for that line, they'd of course be free to do so.
I know there are some current unknowns around 2.2 specifically. I
think stack mentioned to me that there's an upgrade consideration that
we need to hammer out since I don't see anything specific to 2.2 in
the "Upgrade Paths" section of the ref guide right now. While I am
interested in getting 2.2 going specifically, I'd like to make sure we
address the general topic of regularly getting new minor releases out.
If we already had an expectation that there'd be a minor release every
e.g. month or 2 months then I expect whatever upgrade issue would have
been addressed as a part of the change that caused it going in.
What do folks think?
[1]:
https://s.apache.org/AAma
