mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kellen sunderland <kellen.sunderl...@gmail.com>
Subject Re: [Discussion] Branch Usage and Release Versioning
Date Thu, 25 Jan 2018 11:51:39 GMT
+1 (non-binding) to points 1-5.

For point 3 I would suggest we come up with a heuristic for support
status.  For example we announce each release that we are dropping support
for all prior releases that A) have less than 5% pip usage and B) are 3
minor releases old or older.

On Tue, Jan 23, 2018 at 8:12 AM, Steffen Rochel <steffenrochel@gmail.com>
wrote:

>     I support the proposed versioning following https://semver.org/
> including
> the definition of major, minor and patch releases. In my understanding this
> means we are creating branches from master for every major and minor
> release. We will release patches from head of the branches following Apache
> release rules.
>
>
> I agree that we should merge critical bug fixes into older release branches
> and suggest to integrate critical bug fixes from master branch for PR which
> receive at least 3 votes on github. While there should be no limitations on
> back merges into older branches I suggest we create only patch releases on
> the most recent major or minor release.
>
>
> I aggree that we should protect release branches and apply regular
> regressions as soon as our CI/CD setup can support branches. In the
> meantime, we will have to rely on manual testing.
>
>
> Steffen
>
> On Mon, Jan 22, 2018 at 3:54 PM CodingCat <codingcat@apache.org> wrote:
>
> > +1 for 1, 2, 4, 5
> >
> > has the same concern on 3 with Bhavin
> >
> > On Thu, Jan 18, 2018 at 10:51 PM, Bhavin Thaker <bhavinthaker@gmail.com>
> > wrote:
> >
> > > Hi Sheng,
> > >
> > > +1 to  proposals 1, 2, 4 and 5.
> > >
> > > Proposal 3, while ideal, seems less practical because it needs
> > significant
> > > time-effort to maintain code changes across multiple branches and test
> > them
> > > to do periodic releases.
> > >
> > > Our todo list is huge in terms of getting tests fixed, PR reviews
> backlog
> > > getting cleared, having more test cases, etc, etc. I do NOT foresee a
> > > practical way to maintain multiple branches. I propose to maintain only
> > the
> > > latest branch and do releases from the master branch only — at least
> fit
> > > the short term — and revisit this proposal in future when things are
> more
> > > smoother.
> > >
> > > In short, your proposal #3 is good and ideal but seems less practical
> > based
> > > on my observations so far.
> > >
> > > Bhavin Thaker.
> > >
> > > On Thu, Jan 18, 2018 at 12:58 AM Marco de Abreu <
> > > marco.g.abreu@googlemail.com> wrote:
> > >
> > > > Hi Sheng,
> > > >
> > > > very good suggestions! How long do we plan to support old versions?
> > > >
> > > > While the structure of our CI-setup for Ubuntu-based tasks allows
> > proper
> > > > versioning because the entire behaviour is defined in the
> > tests/ci-build
> > > > repository, this is currently not the case for the Windows-tasks.
> While
> > > we
> > > > plan to redesign the entire Windows-slave soon, we're currently in a
> > > state
> > > > which does not allow versioning. Reason being here that the old
> > > > Windows-slave setup, which we had no chance to redesign yet, uses a
> lot
> > > of
> > > > scripts and binaries stored on the Windows-slave itself. Just to give
> > > some
> > > > examples of what's stored on the slave and not managed within GitHub:
> > > > - build_vc14_*.bat: Defines build behaviour for msbuild
> > > > - test_cpu/gpu.bat: Defines test behaviour for python
> > > > - Libraries: Precompiled binaries like Openblas, OpenCV and cudnn
> > > > In case an update on the master requires upgrading a library or
> > changing
> > > > one of the scripts, all other builds would break. It's definitely
> part
> > of
> > > > the Windows-slave-revamp to have the entire behaviour defined inside
> > the
> > > > Jenkinsfile and tests/ci-build.
> > > >
> > > > I totally agree that we should also run protected mode on
> > > version-branches,
> > > > but I'm afraid that the CI is not in a state to support this at the
> > > moment.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > > >
> > > > On Wed, Jan 17, 2018 at 8:01 PM, Sheng Zha <zhasheng@apache.org>
> > wrote:
> > > >
> > > > > Dear community members,
> > > > >
> > > > > Now that we're preparing a new release under the 1.0 version, I'd
> > like
> > > to
> > > > > propose that we discuss, clarify, and decide how we use versions
> and
> > > > > branches.
> > > > >
> > > > > Current practice is:
> > > > > 1. we use master branch for development.
> > > > > 2. we fork from master branch and create release branch for
> specific
> > > > > versions, such as 1.0.0
> > > > > 3. no formal process for bug fixes on those release branches after
> > > > release
> > > > > 4. not agreed on using Semantic Versioning for deciding version
> > number:
> > > > > https://semver.org/ (though technically not breaking it either,
> > > because
> > > > we
> > > > > only had one release for 1.0 so far, which defines the promised set
> > of
> > > > > public APIs)
> > > > >
> > > > > I propose the following changes:
> > > > > 1. we continue to use master branch for development (not really a
> > > change,
> > > > > duh)
> > > > > 2. we create release branches for minor versions, such as 1.0.x,
> > 1.1.x,
> > > > and
> > > > > release from the head of those branches with version numbers
> > according
> > > to
> > > > > semantic versioning.
> > > > > 3. we regularly apply relevant bug fixes to release branches and
> > > provide
> > > > > maintenance releases.
> > > > > 4. we use the same protected branch and CI features to protect our
> > > > release
> > > > > branches (i.e. PR-only, tested at every step)
> > > > > 5. we promise the practice of semantic versioning to users.
> > > > >
> > > > > Note that in order to be able to perform proposed item 3, we need
> > > clarity
> > > > > on whether a PR introduces a new API, and record the version in
> which
> > > it
> > > > > was released. Note that this applies to new argument to existing
> API,
> > > and
> > > > > new semantic meaning of existing APIs and arguments. This way, we
> > know
> > > > > which bug fixes are relevant to which versions.
> > > > >
> > > > > Your thoughts and suggestions are welcome. Thank you for your time.
> > > > >
> > > > > -sz
> > > > >
> > > >
> > >
> >
>

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