[GitHub] [accumulo] ctubbsii commented on issue #1376: Add gc metrics reporting

[GitBox <gi...@apache.org>]

ctubbsii commented on issue #1376: Add gc metrics reporting
URL: https://github.com/apache/accumulo/pull/1376#issuecomment-535772453
 
 
   > Until the 1.9.x branch is declared EOL
   
   By definition (semver), 1.9 already *is* effectively EOL, with respect to new features (at least, those in the public API). While technically your changes don't affect the public API, and are therefore not violations of the semver rules we've agreed to, they do violate the *spirit* of it by introducing behavioral changes that aren't forwards-compatible and by changing user-facing elements, such as the configuration for things other than to fix a bug. In my personal opinion, maintenance releases should be minimal changes that provide for increasingly stable and less buggy versions of a previous ".0" release that are as fully forwards-compatible and have as few user-facing changes as possible. We haven't always been good about this; we should strive to be better.
   
   > Because of the jump between 1.9.x and 2.x that is required by users, there are going to be people using the 1.9.x line for a while.
   
   That's precisely why we should focus on increasingly stable maintenance releases, and not potentially create new problems for 1.9 users. Semver means: upgrade to major/minor for new features, upgrade to maintenance release for increasingly stable with the existing feature set. That's the trade-off. It's intentional. The more we blur those lines, the worse it is for users, trying to reason about risk and reward for upgrading to a particular version.
   
   > Maybe a solution is these types of changes go into a 1.10 release?
   
   That is the right way to do new features in the world of semver. However, I'm not sure how I feel about supporting an additional release line right now. And I have no idea what that might mean for the LTS idea that was raised, or for our ability to continue to support those on 1.9 with maintenance releases, or work on 2.x. That should be discussed on the mailing list.
   
   ****
   
   I do get that you're trying to target your contributions in a way that will see the light of day faster, and that you're putting in the work to support the older version, but I think there's very good reason to add them to the next development version, rather than try to put them in maintenance releases. Putting them in the next development version, rather than a maintenance branch, gives new features more time to be exercised, inspected, tested, checked for alignment with current development direction, and reviewed for correctness, prior to release. It keeps the next version moving forward, and helps releases get out the door faster than they would if we are constantly dealing with merge conflicts, and code reviews across many branches. And, it helps ensure that users can predict the level of risk associated with upgrading to a maintenance release, by providing increasingly stable maintenance releases without the complications or behavior changes associated with new features, and it ensures greater forwards-compatibility. I just don't see the urgency of forcing new features into older branches, rather than targeting them for the next stable version under development. I think it creates more work and has too many downsides.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services