ctubbsii commented on code in PR #3088:
URL: https://github.com/apache/accumulo/pull/3088#discussion_r1027136321
##########
core/src/main/java/org/apache/accumulo/core/client/admin/compaction/CompactionConfigurer.java:
##########
@@ -50,6 +51,12 @@ public interface InitParameters {
public interface InputParameters {
TableId getTableId();
+ /**
+ * @return the id of the tablet being compacted
+ * @since 2.1.1
+ */
+ TabletId getTabletId();
+
Review Comment:
> If enough materialize, then it may be a good reason to release 2.2.0.
If we didn't have the LTM upgrade paths, and were operating under pre-LTM,
then I'd agree. However, LTM expectations makes that more complicated. Would
users move from 2.1 LTM to 2.2 non-LTM for this? If users are willing to go to
non-LTM, why wouldn't they just accept getting these features in 3.x? Are we
expecting to maintain another 2.x LTM release so users can get these, plus
stability patches? If we're still working on 3.x, how many branches are we now
on the hook to maintain? So far, I don't see much compelling here to warrant
more branches to maintain, or for users to be motivated to move off an LTM
release. However, they might decide to backport something like this to their
own internal 2.1 LTM-based fork.
For now, I'd suggest basing this off of the main branch. If we do decide to
have another 2.x version, we can backport it from 3.x to a newly created branch
for that purpose (but I hope we don't because it's too much overhead to
maintain so many different branches and clearly communicate expectations to
users about what they get with each branch).
--
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]
