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