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