Hello, we recently had a few cases in which it has been attempted to add new functionality to old branches because a customer of somebodys $DAY_JOB requested it and was unable to switch to the latest release or that certain feature did not make it into the release. This lead to quite a lot of discussions and there was no clear standing within the community.
Just to cite semantic versioning: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. We as a community agreed on following this system and I think we should either stick to it or drop it entirely - exceptions to SemVer are usually discouraged. While I see that adding functionality might be a minor thing, I don't think that we should educate our users into expecting us to backport new features. The development happening on the Apache MXNet repository should not be influenced by something like this; especially considering that whoever supports that customer on their $DAY_JOB can assist them at creating a fork and cherrypicking that feature. But I don't see much reason why we're running against best pracitices. One important thing to note here is that we're not maintaining CI on old branches and neither are we making patch releases - so what do these users do? Compile off a stale development branch with unvalidated changes? In my opinion this whole topic is just causing trouble and fragementation on our end. If a features doesn't make it into the release (for whatever reason), so be it. But I think we should discuss this topic and emphasize a no-exceptions-rule to SemVer. Best regards, Marco
