You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by GitBox <gi...@apache.org> on 2022/11/22 10:04:13 UTC
[GitHub] [accumulo] keith-turner opened a new issue, #3092: Backport candidates for potential 2.2
keith-turner opened a new issue, #3092:
URL: https://github.com/apache/accumulo/issues/3092
This issue exists to track potential 3.0 changes that may motivate a 2.2 release. However there may never be a 2.2 release if there are not enough issues. See this [discussion](https://github.com/apache/accumulo/pull/3088#discussion_r1027114511)
* #3088
--
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: notifications-unsubscribe@accumulo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
dlmarion commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1331229769
> But it's the "more branches to maintain" that I'm hoping to avoid.
I agree, that's a concern.
> However, I'd rather focus on 3.0, and put the proposed additions there. I just don't see much urgency to include these proposed features as a 2.x update instead of just rolling them into 3.0.
I think the issue here is that:
1. 2.1 was decided as a LTM release too early
2. we don't have a timeline for 3.x
I would be on board with moving my features to 3.x if I knew more about its timeline. In fact, I would propose something like (dates are hypothetical):
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)
3.2.0 - feature set B (release Dec 2023)
LTM - when we're done and need to make breaking changes for 4.x
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
EdColeman commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1323653594
If this continues to grow, my opinion is that it should be a project.
Continuing the discussion - I very much prefer leveraging GH issues and projects for tracking things over a personnel lists - that allows everyone to track / have visibility into things and relieves me of the burden of making my own list, keeping it up to date and tracking it myself.
The advantage of projects is that is tracks multiple issues and shows outstanding vs completed independent of the individual issues.
Being able to review open issues on GH allows me to judge where things stand and what people are thinking about. If there are areas of code that I think could use some attention, knowing what other potential changes should be considered might help deconflict what I might propose. If it was aon someone's private list, then I have no visibility and need to rely on someone noticing my change and realizing that it may brush on things that could be impacted.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
ctubbsii commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1331187429
@dlmarion You're right. But it's the "more branches to maintain" that I'm hoping to avoid. It might not be so bad if the changes are very minimal, but it would basically mean releasing a new 2.2\+ version every time we release a 2.1 LTM patch if we want people on those versions to also have the patch. However, I'd rather focus on 3.0, and put the proposed additions there. I just don't see much urgency to include these proposed features as a 2.x update instead of just rolling them into 3.0.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
ctubbsii commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1324533452
Regardless of where you track this list (and I would prefer a "project" (we've been using the "classic" projects) over an issue that is more easily lost, I don't think we need to include things that are already staged for a 2.1 patch release, unless we're trying to argue that the 2.2 should replace the 2.1 as a continuation of that "LTM" series. But, that could get really confusing, suggesting that risk-averse users jump a minor release when they chose to stay on LTM releases to avoid the risks associated with new features.
Then again, we can just say "oops, our mistake", 2.1.0 is not an LTM release, but 2.2.0 is. But then, when does it stop? Maybe next time we do a .0 release, we do an initial release as non-LTM, and then only decide it's going to be an LTM release later? I don't know what's least confusing to users trying to track the version hell.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
ctubbsii commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1324536713
I didn't see the earlier discussion on #3088 that suggested an issue instead of a project, so it's less noisy. Either way works for me.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
dlmarion commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1329720511
Re-reading the [LTM](https://accumulo.apache.org/contributor/versioning#LTM) page, it doesn't preclude a 2.2.0, 2.3.0, etc., it just says that as a non-LTM release any patches/bugfixes would be released in a subsequent minor version. This allows us to continue to release features on the 2.x line (even experimental ones). The downside here is that we end up with more branches to maintain. I feel like if we did some planning we could find consensus on a path forward.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] keith-turner commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
keith-turner commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1326566623
> would there be a 2.1.2 after a 2.2.0?
No, not if following was done w/ 1.8.0 onward. It was a linear progression.
> So, I'm inclined to bump things to 3.0 that would not be appropriate for 2.1 patch releases because of semver.
Another option to consider is that we accept exceptions to semver in the 2.1.x line as long as they are well documented in release notes and javadoc. This was discussed on one or more of the PRs.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3092: Backport candidates for potential 2.2
Posted by GitBox <gi...@apache.org>.
ctubbsii commented on issue #3092:
URL: https://github.com/apache/accumulo/issues/3092#issuecomment-1326424608
@keith-turner thank you for laying out your thoughts. One thing to consider regarding the path of least surprise that we've done before, is that we did that before establishing the LTM release strategy, which adds an extra dimension to consider. One of the goals of that is to keep a more and more stable feature fixed release line, and not just a minimal, least surprise, series of minor release feature additions. It's easy to communicate that 2.1 is LTM, but much more confusing to users that the version range `[2.1,2.3)` is a single LTM "version". It also complicated potential upgrade paths and maintenance branches we develop (would there be a 2.1.2 after a 2.2.0? Users may expect one because it's in the LTM range).
So, I'm inclined to bump things to 3.0 that would not be appropriate for 2.1 patch releases because of semver.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org