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 >
