mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <>
Subject Re: Following semantic versioning
Date Tue, 06 Mar 2018 00:20:08 GMT
Maybe we could gather items our users would like to have before we cut the
release and make sure that they are included? This would show them that
we're genuinely interest in their demands and avoids problems like this at
the same time.

There are two reasons CI is not running older branches:
1. The Windows setup is not made in a way that supports multiple branches
(means that dependencies and setup scripts can not be versionized).
Eftiquar is currently working on resolving this.
2. I'm the only person working and maintaining the CI system, leading to
heavy resource constraints and  thus dropping support for all branches
other than the master branch.

One thing to note is that the Windows setup has not been changed within the
last 4 months (or maybe even more, but that's when the new CI has been put
into production), so #1 is not a blocker *at the moment*. Considering that
the entire configuration for CI (besides the mentioned Windows part) is
stored in the GitHub repository itself, backporting changes and re-enabling
CI on past branches can be done by anybody by simply issuing a PR to the
respective branch.

I agree that we should have patch releases on released branches in order to
provide our users with proper support (especially considering bugfixes we


On Tue, Mar 6, 2018 at 12:56 AM, Naveen Swamy <> wrote:

> 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 <
> > 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message