ctubbsii commented on issue #3092: URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1331325874
> * 2.1 was decided as a LTM release too early I don't agree with that. LTM releases are intended to be feature frozen up front so we can have a target to maintain as stable. I think the issues we're seeing is growing pains as we get used to that idea, and we're seeing a desire to add features here and there that weren't ready (or even known to be desired) until too late. From my perspective, it feels like the intent of LTM is being undermined by a regret of not having everything we wanted. But the constant flux of features without a predetermined stable version that we were intending to maintain is the *main* problem we were trying to fix by having LTM releases in the first place. We can still have those features... in the next version... but not in the LTM one... that's the whole point. New features can wait until the next version, and users can decide for themselves if they want to stay on the LTM release or move forward with new features and incur additional risk. We let the user decide that by communicating very clearly w hat the LTM is and isn't. > * we don't have a timeline for 3.x That's fair, but we don't have a timeline for any 2.2 release either. Any plan for 2.2 to include these features can just be a plan for 3.0 to include those same features. I'm not opposed to a 2.2 in principal. I just don't think we need to limit how much we take on in terms of maintenance branches to reduce confusion for users and to manage our limited contributor resources. In fact, I think it's a good idea, in general, to make the LTM release the last minor release before moving to a new major release, because it helps users who aren't ready to upgrade and risk API breakages have confidence that the version will be maintained for a while and they won't have to upgrade. > 3.0.0 - removal of deprecated items only (release date January or February - as early as possible) > 3.1.0 - feature set A (release June 2023) Your proposed timeline seems reasonable. Originally, I had wanted a 3.0 in December. It might be attainable, but would be rough with people taking time off for holidays. January seems more likely. I had wanted to push to keep 3.0.0 really minimal, in terms of new features, so we could release it quickly after stripping out deprecations to clean up and set the stage for subsequent changes free of old baggage that limited our development. However, I did not anticipate small new features that were ready so quickly, prior to 3.0.0 being released. I think it would be okay to add a few small changes in 3.0.0, as long as they don't delay the release, and aren't disruptive to the main cleanup tasks. I think the changes proposed so far are likely in that category. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
