There is a issue already for completing HBCK2
https://issues.apache.org/jira/browse/HBASE-21745
Andrew Purtell 于2019年1月22日周二 上午9:57写道：
> I think a fully functional hbck2 is a prerequisite for moving the stable
> pointer. See the other thread on that. Otherwise, it seems fine if there is
>
I think a fully functional hbck2 is a prerequisite for moving the stable
pointer. See the other thread on that. Otherwise, it seems fine if there is
consensus to move it.
On Mon, Jan 21, 2019 at 5:50 PM Stack wrote:
> Thanks Andrew. I think there are others too who have the same predicament
>
Thanks Andrew. I think there are others too who have the same predicament
(Francis Liu for instance). Backports of perf improvements, bug fixes, and
operational tooling improvements makes sense while branch-1 is in active
use.
I appreciate Allans' sentiment. It is time to move the stable pointer
I can speak for myself and assume others backporting to branch-1 have similar
motivations. We are backporting interesting and useful and reasonable
improvements, because branch-1 is still useful and in production, and will be
for the foreseeable future. Changes like perf improvements and
{quote}
For example, you release 2.1.0 yesterday, 1.5.0 today, and then 2.1.1
tomorrow, it is OK that 2.1.0 does not have all feature which 1.5.0 has,
but 2.1.1 should have all features which 1.5.0 has.
{quote}
I don't think can work, normal user mostly won't care about the release
time, they only
As branch RM for branch-1 I will always check to make sure a commit there has
first been committed to branch-2. There will always be an upgrade path from a
branch-1 based release to a branch-2 based release. The relevant JIRAs will
either have a 1.x and 2.x fixVersion or the backport JIRA will
I agree with Andrew that we can't both have maintenance releases and expect
every feature in ongoing branch-1 releases to be in branches-2.y.
Tracking consideration for when features are available across major
versions fits in well with the "upgrade paths" section in the ref guide.
We've just
Then we must have a upgrade path, for example, 1.5.x can only be upgraded
to 2.2.x if you want all the features still there?
Maybe we should have a release timeline for the first release of all the
minor releases? So when user want to upgrade, they can choose the minor
release which is released
Also I think branch-1 releases will be done on a monthly cadence independent of
any branch-2 releases. This is because there are different RMs at work with
different needs and schedules.
I can certainly help out some with branch-2 releasing if you need it, FWIW.
It may also help if we begin
Also please be prepared to support forward evolution and maintenance of
branch-1 for, potentially, years. Because it is used in production and will
continue to do so for a long time. Features may end up in 1.6.0 that only
appear in 2.3 or 2.4. And in 1.7 that only appear in 2.5 or 2.6. This
This can't work, because we can put things into a new minor that cannot go into
a patch relesse. If you say instead 2.2.0 must have everything in 1.5.0, it can
work. The alignment of features should happen at the minor releases. If we can
also have alignment in patch releases too, that would be
And yes we should document this.
And also we need to have a web page to list all the releases in timeline?
So user could know which version is safe to use when upgrading easily.
张铎(Duo Zhang) 于2019年1月19日周六 上午11:12写道：
> Please see the red words carefully, I explicitly mentioned that, the newer
Please see the red words carefully, I explicitly mentioned that, the newer
version should be released LATER, if you want to get all the features.
For example, you release 2.1.0 yesterday, 1.5.0 today, and then 2.1.1
tomorrow, it is OK that 2.1.0 does not have all feature which 1.5.0 has,
but
Consider that we actually cannot guarantee this without a time machine, because
some "newer" versions are already released.
If we backport to 1.5 now, we cannot do anything about 2.0.0, 2.1.0, 2.1.2,
etc. because they are already released... if the user upgrades from 1.5 to
2.0.1 for example,
14 matches
Mail list logo
