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