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