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 <[email protected]> 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 <[email protected]> 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 ??? > > > > > >
