The following document was approved by the Technical Committee on July 20, 2017.
ADAPT uses the Semantic Versioning 2.0.0, described at http://semver.org/spec/v2.0.0.html.
ADAPT uses the Git Flow versioning model as described at http://nvie.com/posts/a-successful-git-branching-model/.
Pull requests to ADAPT (outside of emergency hotfixes) are submitted to the develop branch. The develop branch always represents work being included for the next release of ADAPT. The technical leaders decide what type of release (patch, minor, major) will be the next release for ADAPT. The next release’s type guides what pull requests will be merged and which will be delayed for future releases. (Learn more later)
Pull requests for changes must be forked from the develop branch and submitted back to the develop branch. For example, if a contributor adding a new property to an existing class which is already in develop should do the following:
Pull requests which represent changes to a feature which hasn’t been merged into the develop must be branched from and submitted back to the submitter’s repository on the develop branch. For example, if user ‘alice’ adds a new property to a class which user ‘bob’ has submitted a pull request for but it hasn’t been merged into develop, ‘alice’ should do the following:
Emergency bugfixes may be made only for the current release on master. Bugfixes will be submitted as pull requests and, if appropriate, merged based on the bug fix process of Git Flow. Emergency Bugfixes are for very rare situations where a bug must be fixed immediately and develop is not ready for a release.
Technical team members and the general public are welcome to comment on pull requests and give suggestions.
Once a pull request is submitted for inclusion (normally that’s when a pull request is submitted), the technical team will evaluate that pull request at the next meeting of the technical team. They will use the following process:
Any elements which will be removed as part of this major version change must be marked as deprecated for one major version. This provides users with sufficient time to know about changes and fully prepare for the change.
Processing pull requests requiring a major version change should follow this process (after following the initial steps listed in "Evaluating pull requests on AgGateway/ADAPT":
Develop represents the next version to be prepared for release. By default, the next version type is a patch release. The technical team will decide via majority vote whether to change the next release type to minor or major. Once a decision has been made on what the next release type is, the technical team will notify the community in the following manner:
The technical team will begin processing the pull requests which have been marked as being appropriate for this version state. For example, if next version type is a minor release, all minor pull requests will be processed for inclusion. If the pull requests are out of date, the submitter must fix them before merger.
Release branch changes
Changes can only be submitted to the release branch for bug fixes. Those bugfixes must be merged into develop immediately after merger into a release branch A release branch can be open for a very short period (simply long enough to formally create the branch and finalize the release) or longer based upon the community testing required for the release.
The technical team will decide via majority vote when to finalize a release. Upon release finalization, the release branch will be merged into master and the commit will be tagged with the version. Merging and tagging should trigger the official NuGet.org package creation and posting. The release branch will be closed.
Development packages have two subsets: develop branch and prerelease. Develop branch packages are automatically created no more frequently that once daily from the contents of the develop branch and are posted to NuGet with the postfix of "DATE-nightly" where date is in the 'YYYYMMDD' format. These packages provide very early testing for those who use ADAPT from NuGet.
Prerelease packages are automatically created no more frequently than once daily from the contents of a release branch. These versions are marked as prerelease and are posted to NuGet.org. This provides early testing for new versions.