+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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 < > > > [email protected]> 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 <[email protected]> > > 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 > > > > > > > > > > > > > > >
