What happens if nobody is interested in being a release manager for a version? What happens if the schedule is missed? - Then there is no release. I would imagine if we can find the right time frame and devs are actively working, this won't be a problem though. Perhaps simplifying the release process would help ease the burden of releasing.
Who handles reminders for scheduling new releases? - We can post the schedule. Reminders are optional, if someone wants to notify the community they can. Will we establish freeze deadlines for features? How do we enforce freezes in the C-T-R model? - I think that is a good idea. We could do an API freeze further out, say like 3 months. Then a full freeze a week before. A tag could be created to freeze the code. 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? - Same as my first comment. I also think "compelling" is difficult to define, so we shouldn't worry about that. A single bug fix could be compelling to someone. I think its different for everyone. Even a LTS release that is 100% bug fixes with no new features could be compelling to a team who is resistant to upgrading. On Fri, Aug 2, 2019 at 2:35 PM Christopher <[email protected]> wrote: > 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. >
