You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Ed Coleman <ed...@apache.org> on 2021/10/20 00:16:40 UTC
[DISCUSS] Version number of next release?
I stared a general thread concerning topics for the next release. One major topic raised was what should the next version number be? I stared this thread so that version discussions can occur in a single thread for continuity. From the general email thread:
Version number: There have been substantial changes since 2.0 was released. The next version was expected to be 2.1, but with the number and the scope of changes that have been made and some that are in the pipeline, maybe we should signal this with a major version bump to 3.0?
- With semver, we might be able to go either way, depending on interpretation.
- With the adoption of LTM releases, whatever the next version is numbered, it will be a LTM release candidate.
- There have been over 800 changes committed.
- Notable major changes:
o Name changes to inclusive language (Manager instead of Master,…)
o Enabling external compactions.
o Changes in the storage of properties in ZooKeeper to reduce watchers (in progress, issues #1225, #1809)
o Change tracing to use OpenTracing instead of HTrace (PR #2259)
o Change metrics to use micrometer.io instead of Hadoop-metrics2 (PR #2305)
o Changes to enable per-table encryption and other improvements (PR #2197)
o ???
Re: [DISCUSS] Version number of next release?
Posted by Mike Miller <mm...@apache.org>.
I am worried that creating a "good opportunity to do some cleanup" with a
3.0 LTM will only push the release back further and create a larger gap
between LTM releases. The jump from 1.10 to 2.X is already challenging
enough for users. Also, 4 of the large changes Ed mentioned have yet to be
completed or merged:
o Changes in the storage of properties in ZooKeeper to reduce watchers
(in progress, issues #1225, #1809)
o Change tracing to use OpenTracing instead of HTrace (PR #2259)
o Change metrics to use micrometer.io instead of Hadoop-metrics2 (PR
#2305)
o Changes to enable per-table encryption and other improvements (PR
#2197)
Some of these changes could go in the next version. We could have a release
of 2.1 LTM now to include all the changes since 2.0 was released. I don't
like the idea of users having to go from 1.10 to a 3.0 version, skipping a
major version and never releasing a 2.x LTM version. I think having a 2.1
release now might make it easier for users going forward and give all the
new features in 2.X an opportunity to be hardened in bug fix releases.
Accumulo has yet to do a release in 2021.
Also, if we do find a change with the Master to manager rename that creates
an incompatibility it may not be that difficult to just revert that change
for a 2.1 release.
On Wed, Oct 20, 2021 at 1:36 AM Christopher <ct...@apache.org> wrote:
> We wouldn't *have* to remove additional deprecations if we did name it
> 3.0, but it might be a good opportunity to do some cleanup for some
> stuff that deprecated prior to 2.0, but left in there to ease the
> transition to 2.0. Then again, removing anything else might make the
> transition from 1.10 LTM to 3.0 LTM more challenging.
>
> Unless we find a clear compatibility issue in our public API that
> forces us to bump to 3.0 because of semver, I'd be okay with either
> version, so long as we make a decision. I do think the substantial
> metrics/property name/tracing changes are compelling reasons to go to
> 3.0, because even if they don't cause problems with our public API,
> the changes may still cause headaches for sysadmins.
>
> On Tue, Oct 19, 2021 at 8:16 PM Ed Coleman <ed...@apache.org> wrote:
> >
> > I stared a general thread concerning topics for the next release. One
> major topic raised was what should the next version number be? I stared
> this thread so that version discussions can occur in a single thread for
> continuity. From the general email thread:
> >
> > Version number: There have been substantial changes since 2.0 was
> released. The next version was expected to be 2.1, but with the number
> and the scope of changes that have been made and some that are in the
> pipeline, maybe we should signal this with a major version bump to 3.0?
> >
> > - With semver, we might be able to go either way, depending on
> interpretation.
> > - With the adoption of LTM releases, whatever the next version is
> numbered, it will be a LTM release candidate.
> > - There have been over 800 changes committed.
> > - Notable major changes:
> > o Name changes to inclusive language (Manager instead of Master,…)
> > o Enabling external compactions.
> > o Changes in the storage of properties in ZooKeeper to reduce
> watchers (in progress, issues #1225, #1809)
> > o Change tracing to use OpenTracing instead of HTrace (PR #2259)
> > o Change metrics to use micrometer.io instead of Hadoop-metrics2
> (PR #2305)
> > o Changes to enable per-table encryption and other improvements
> (PR #2197)
> > o ???
> >
> >
> >
>
Re: [DISCUSS] Version number of next release?
Posted by Dave Marion <dm...@gmail.com>.
I'd like to make the case for staying with 2.1. My main motivation for this
is the slow speed at which users upgrade and the perceived risk of the
number 3.0 (vs 2.1). I think users would see "3.0" and think that it would
require a lot more work to upgrade to it than "2.1". Moving to 3.0 has a
consequence in that we have publicized that we version using semver rules,
so bumping the major version implies that there is a breaking change in the
API. I can't speak to the amount of testing that users perform, but it will
give them a sense that their application needs to be updated/fixed to work
with the new version. We have recently seen this[1].
Technically, I think there is one issue[2] in the client API that would
mandate us using 3.0 as the next version, but I think it could be easily
fixed. As for some of the other changes in main currently, some of them
will not affect existing systems as they are new optional features (e.g.
external compactions) and some of them will only affect existing systems
that use the feature (e.g. metrics, tracing, accumulo-cluster script
changes). Regarding cluster admin changes (master -> manager, scripts,
etc), the release notes should highlight the change and point to more
information (user guide, GitHub issue, etc.) on how admins should adjust.
It would be great to get feedback from users and downstream integrators in
general, and specifically on things like upgrading, as it would help make
the "right" choice here.
[1]
https://lists.apache.org/thread.html/rfaab4a8fa2b98df3d41dabae4c63a35a75d9cd293de8c1cd28f83eb3%40%3Cdev.accumulo.apache.org%3E
[2] https://the-asf.slack.com/archives/CERNB8NDC/p1634819762001300
On Thu, Oct 21, 2021 at 10:49 AM Keith Turner <ke...@deenlo.com> wrote:
> If we were to move to 3.0, it would be nice to reach consensus on the
> specific reasons why we are doing it. If this were to include
> dropping deprecated APIs it would be nice to identify which APIs would
> be dropped and why before deciding. This way people can make an
> informed decision about supporting the move to 3.0. If the reasons to
> move to 3.0 are decided after the fact, it's hard for me to know if I
> support the move.
>
> For example, we could try to obtain consensus on a list like the
> following as the reasons for moving to 3.0 before moving to 3.0.
>
> * Metrics incompatibility
> * Tracing incompatibility
> * accumulo-cluster script incompatibility
> * Possible incompatibility due to master -> manager renaming
> * Dropping API x.y.z because ...
> * Dropping API a.b.c because ...
>
> This would also serve as good documentation for the release notes
> eventually, listing the explicit reasons that 3.0 was chosen.
>
> Also I agree that we do need to work towards getting a 2.1 or 3.0
> release done sooner rather than later.
>
> On Wed, Oct 20, 2021 at 1:36 AM Christopher <ct...@apache.org> wrote:
> >
> > We wouldn't *have* to remove additional deprecations if we did name it
> > 3.0, but it might be a good opportunity to do some cleanup for some
> > stuff that deprecated prior to 2.0, but left in there to ease the
> > transition to 2.0. Then again, removing anything else might make the
> > transition from 1.10 LTM to 3.0 LTM more challenging.
> >
> > Unless we find a clear compatibility issue in our public API that
> > forces us to bump to 3.0 because of semver, I'd be okay with either
> > version, so long as we make a decision. I do think the substantial
> > metrics/property name/tracing changes are compelling reasons to go to
> > 3.0, because even if they don't cause problems with our public API,
> > the changes may still cause headaches for sysadmins.
> >
> > On Tue, Oct 19, 2021 at 8:16 PM Ed Coleman <ed...@apache.org> wrote:
> > >
> > > I stared a general thread concerning topics for the next release. One
> major topic raised was what should the next version number be? I stared
> this thread so that version discussions can occur in a single thread for
> continuity. From the general email thread:
> > >
> > > Version number: There have been substantial changes since 2.0 was
> released. The next version was expected to be 2.1, but with the number
> and the scope of changes that have been made and some that are in the
> pipeline, maybe we should signal this with a major version bump to 3.0?
> > >
> > > - With semver, we might be able to go either way, depending on
> interpretation.
> > > - With the adoption of LTM releases, whatever the next version
> is numbered, it will be a LTM release candidate.
> > > - There have been over 800 changes committed.
> > > - Notable major changes:
> > > o Name changes to inclusive language (Manager instead of
> Master,…)
> > > o Enabling external compactions.
> > > o Changes in the storage of properties in ZooKeeper to reduce
> watchers (in progress, issues #1225, #1809)
> > > o Change tracing to use OpenTracing instead of HTrace (PR #2259)
> > > o Change metrics to use micrometer.io instead of
> Hadoop-metrics2 (PR #2305)
> > > o Changes to enable per-table encryption and other improvements
> (PR #2197)
> > > o ???
> > >
> > >
> > >
>
Re: [DISCUSS] Version number of next release?
Posted by Keith Turner <ke...@deenlo.com>.
If we were to move to 3.0, it would be nice to reach consensus on the
specific reasons why we are doing it. If this were to include
dropping deprecated APIs it would be nice to identify which APIs would
be dropped and why before deciding. This way people can make an
informed decision about supporting the move to 3.0. If the reasons to
move to 3.0 are decided after the fact, it's hard for me to know if I
support the move.
For example, we could try to obtain consensus on a list like the
following as the reasons for moving to 3.0 before moving to 3.0.
* Metrics incompatibility
* Tracing incompatibility
* accumulo-cluster script incompatibility
* Possible incompatibility due to master -> manager renaming
* Dropping API x.y.z because ...
* Dropping API a.b.c because ...
This would also serve as good documentation for the release notes
eventually, listing the explicit reasons that 3.0 was chosen.
Also I agree that we do need to work towards getting a 2.1 or 3.0
release done sooner rather than later.
On Wed, Oct 20, 2021 at 1:36 AM Christopher <ct...@apache.org> wrote:
>
> We wouldn't *have* to remove additional deprecations if we did name it
> 3.0, but it might be a good opportunity to do some cleanup for some
> stuff that deprecated prior to 2.0, but left in there to ease the
> transition to 2.0. Then again, removing anything else might make the
> transition from 1.10 LTM to 3.0 LTM more challenging.
>
> Unless we find a clear compatibility issue in our public API that
> forces us to bump to 3.0 because of semver, I'd be okay with either
> version, so long as we make a decision. I do think the substantial
> metrics/property name/tracing changes are compelling reasons to go to
> 3.0, because even if they don't cause problems with our public API,
> the changes may still cause headaches for sysadmins.
>
> On Tue, Oct 19, 2021 at 8:16 PM Ed Coleman <ed...@apache.org> wrote:
> >
> > I stared a general thread concerning topics for the next release. One major topic raised was what should the next version number be? I stared this thread so that version discussions can occur in a single thread for continuity. From the general email thread:
> >
> > Version number: There have been substantial changes since 2.0 was released. The next version was expected to be 2.1, but with the number and the scope of changes that have been made and some that are in the pipeline, maybe we should signal this with a major version bump to 3.0?
> >
> > - With semver, we might be able to go either way, depending on interpretation.
> > - With the adoption of LTM releases, whatever the next version is numbered, it will be a LTM release candidate.
> > - There have been over 800 changes committed.
> > - Notable major changes:
> > o Name changes to inclusive language (Manager instead of Master,…)
> > o Enabling external compactions.
> > o Changes in the storage of properties in ZooKeeper to reduce watchers (in progress, issues #1225, #1809)
> > o Change tracing to use OpenTracing instead of HTrace (PR #2259)
> > o Change metrics to use micrometer.io instead of Hadoop-metrics2 (PR #2305)
> > o Changes to enable per-table encryption and other improvements (PR #2197)
> > o ???
> >
> >
> >
Re: [DISCUSS] Version number of next release?
Posted by Christopher <ct...@apache.org>.
We wouldn't *have* to remove additional deprecations if we did name it
3.0, but it might be a good opportunity to do some cleanup for some
stuff that deprecated prior to 2.0, but left in there to ease the
transition to 2.0. Then again, removing anything else might make the
transition from 1.10 LTM to 3.0 LTM more challenging.
Unless we find a clear compatibility issue in our public API that
forces us to bump to 3.0 because of semver, I'd be okay with either
version, so long as we make a decision. I do think the substantial
metrics/property name/tracing changes are compelling reasons to go to
3.0, because even if they don't cause problems with our public API,
the changes may still cause headaches for sysadmins.
On Tue, Oct 19, 2021 at 8:16 PM Ed Coleman <ed...@apache.org> wrote:
>
> I stared a general thread concerning topics for the next release. One major topic raised was what should the next version number be? I stared this thread so that version discussions can occur in a single thread for continuity. From the general email thread:
>
> Version number: There have been substantial changes since 2.0 was released. The next version was expected to be 2.1, but with the number and the scope of changes that have been made and some that are in the pipeline, maybe we should signal this with a major version bump to 3.0?
>
> - With semver, we might be able to go either way, depending on interpretation.
> - With the adoption of LTM releases, whatever the next version is numbered, it will be a LTM release candidate.
> - There have been over 800 changes committed.
> - Notable major changes:
> o Name changes to inclusive language (Manager instead of Master,…)
> o Enabling external compactions.
> o Changes in the storage of properties in ZooKeeper to reduce watchers (in progress, issues #1225, #1809)
> o Change tracing to use OpenTracing instead of HTrace (PR #2259)
> o Change metrics to use micrometer.io instead of Hadoop-metrics2 (PR #2305)
> o Changes to enable per-table encryption and other improvements (PR #2197)
> o ???
>
>
>