I'm in favor of this generally, but worry a bit about making release schedule guarantees, due to the volunteer nature of the project Apache projects in general.
What happens if nobody is interested in being a release manager for a version? What happens if the schedule is missed? Who handles reminders for scheduling new releases? Will we establish freeze deadlines for features? How do we enforce freezes in the C-T-R model? What if there's nothing compelling a release when a scheduled release is approaching? What happens if a scheduled release is approaching, but the community is focused on critical patches for a previous release? On Fri, Aug 2, 2019 at 12:43 PM Keith Turner <[email protected]> wrote: > > I am in favor of this. One possible way to move this forward would be > to write the following two proposals. > > * Transition proposal : lays out how we will transition to this > plan. For example it could outline that 1.9 will become the first > LTS. > * Release schedule proposal : lays out how the Accumulo release > schedule would work. > > The proposals could be made as website PRs and discussion could happen > on the PR. If the proposals are adopted by the community, then they > could be turned into documentation. > > On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <[email protected]> wrote: > > > > I think it would be good for Accumulo to adopt a Long Term Support (LTS) > > type release schedule. It seems to work well for other projects like > > Ubuntu and now Java is doing the same. We could have 2 branches of LTS > > versions, similar to what we have now with 1.9 and 2.0. Then set a > > schedule, say every 6 months or a year, release a minor/major version. For > > example: > > > > 1.9.0 LTS released April 2018 > > 2.0.0 LTS released August 2019 > > 1.10.0 LTS scheduled to release April 2020 > > 2.x.0 LTS scheduled to release August 2021 > > > > Bug fixes for the versions can be released as needed. We can even release > > minor versions, like 2.1.0 just as a tag, and then merge into the main 2.x > > branch. That way we only ever have to deal with 2 branches. The > > motivation for this is to not have so much time (and so many changes) > > between releases like we did for 2.0. This would also help users with > > scheduling upgrades.
