I think its important to understand someone's day_job's customer is also a user of MXNet. Right now MXNet project needs to put effort in helping users and bringing them on-board. I don't think its a good idea to ask the customer to come back after a new release is made or ask to use a fork.
With regards to CI test not running on a older branch, I don't think its Ok to ditch a released branch just because a release was made. why are tests not triggered when a PR is made on an older branch(regardless of new feature or a bug fix) ?. May be we should think about making minor releases on released branches. On Mon, Mar 5, 2018 at 3:25 PM, Marco de Abreu <marco.g.ab...@googlemail.com > wrote: > 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 >
