Date: Fri, 29 Mar 2024 08:19:04 +0000 (UTC) Message-ID: <1700173397.5.1711700344145@ba057c8a0c63> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4_1771187433.1711700344145" ------=_Part_4_1771187433.1711700344145 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The following document was approved by the Technical Committee o= n 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/<= /a>.
Pull requests to ADAPT (outside of emergency hotfixes) are submitted to = the develop branch. The develop branch always represents work being include= d 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=E2=80=99s type guides what pull requests will be merged and which w= ill be delayed for future releases. (Learn more later)
Pull requests for changes must be forked from the develop branch and sub= mitted back to the develop branch. For example, if a contributor adding a n= ew property to an existing class which is already in develop should do the = following:
Pull requests which represent changes to a feature which hasn=E2=80=99t = been merged into the develop must be branched from and submitted back to th= e submitter=E2=80=99s repository on the develop branch. For example, if use= r =E2=80=98alice=E2=80=99 adds a new property to a class which user =E2=80= =98bob=E2=80=99 has submitted a pull request for but it hasn=E2=80=99t been= merged into develop, =E2=80=98alice=E2=80=99 should do the following:
Emergency bugfixes may be made only for the current release on master. B= ugfixes will be submitted as pull requests and, if appropriate, merge= d 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 r= eady 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=E2=80=99s = when a pull request is submitted), the technical team will evaluate that pu= ll request at the next meeting of the technical team. They will use the fol= lowing 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 wit= h sufficient time to know about changes and fully prepare for the change.= p>
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 defau= lt, the next version type is a patch release. The technical team will decid= e via majority vote whether to change the next release type to minor or maj= or. Once a decision has been made on what the next release type is, t= he technical team will notify the community in the following manner:
The technical team will begin processing the pull requests which have be= en 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 fi= x them before merger.
R= elease 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 relea= se 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 b= ased upon the community testing required for the release.
The technical team will decide via majority vote when to finalize a rele= ase. Upon release finalization, the release branch will be merged int= o 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. De= velop branch packages are automatically created no more frequently that onc= e daily from the contents of the develop branch and are posted to NuGet wit= h the postfix of "DATE-nightly" where date is in the 'YYYYMMDD' format. The= se packages provide very early testing for those who use ADAPT from NuGet.<= /p>
Prerelease packages are automatically created no more frequently than on= ce daily from the contents of a release branch. These versions are marked a= s prerelease and are posted to NuGet.org. This provides early testing for ne= w versions.