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 ??? > > >
