mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CodingCat <coding...@apache.org>
Subject Re: [Discussion] Branch Usage and Release Versioning
Date Mon, 22 Jan 2018 23:54:12 GMT
+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