diff --git a/.github/ISSUE_TEMPLATE/release-candidate-review.md b/.github/ISSUE_TEMPLATE/release-candidate-review.md new file mode 100644 index 00000000..debcf96a --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release-candidate-review.md @@ -0,0 +1,18 @@ +--- +name: Release Candidate Review +about: Request OMF review of a Release Candidate +title: Review Release Candidate [X.Y.Z] +labels: admin +assignees: jfh01 + +--- + +### Summary + +The Release Candidate for MDS `X.Y.Z` has been submitted: + +Please use this issue to track Technology Council and OMF Board feedback and/or requested changes. + +### Action Item + +Please close this Issue upon OMF Board Approval to indicate that the Release Candidate may be made official. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 05509943..af50287c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,9 @@ # MDS Contributor Guidelines + MDS is an evolving specification with a regular release cycle. Please review the [MDS Release Guidelines](ReleaseGuidelines.md) to understand the release process. ## Who can contribute + MDS is an open specification and anyone can contribute to its development. Because MDS supports a growing ecosystem of mobility services, policies, and tools, there are some key stakeholders whose participation is particularly encouraged: * **Public agencies:** As licensing authority and regulator, public agencies are the ultimate customers for MDS and the data flowing through it. The public agency role is to ensure that MDS effectively supports program management and offers a flexible foundation for policy implementation. Public agencies of all levels of technical capacity are encourage to participate in the evolution of MDS, whether by submitting pull requests and issues, or simply by providing feedback during release cycles. @@ -11,6 +13,7 @@ MDS is an open specification and anyone can contribute to its development. Becau * **Public agency software partners:** Serve as a key bridge between public agencies and mobility service providers by offering tools that turn MDS data into useful insights. The public agency software partners help ensure that MDS will enable real-world product development, reflects the needs of their public agency customers, and encourages private investment in the MDS ecosystem. ## How to contribute + Contributions should be offered through GitHub issues and pull requests. Please review the [MDS Release Guidelines](ReleaseGuidelines.md) for details on the release process, schedule, and communications channels. In general, you may open an issue or make a pull request at any time. Once the issue or pull request is associated with a particular Milestone, it will be included for review within the process for that release. @@ -18,9 +21,11 @@ In general, you may open an issue or make a pull request at any time. Once the i All contributors must agree to the Open Mobility Foundation's [Individual Contributor License Agreement](http://members.openmobilityfoundation.org/wp-content/uploads/2019/06/Individual-CLA.pdf) (ICLA) and [Participation Policies](https://members.openmobilityfoundation.org/wp-content/uploads/2019/06/OMFParticipationPolicies.pdf). Pull requests will not be merged without a signed ICLA. If a contributor is working on behalf of a company or other organization, that organization must also agree to the [Entity Contributor License Agreement](https://members.openmobilityfoundation.org/wp-content/uploads/2019/06/Entity-CLA.pdf) (ECLA). These agreements clarify the intellectual property status of work that is contributed to OMF projects. They apply to all contributions, including source code, documentation, and comments. ## What belongs in MDS + MDS is a tool to facilitate data exchange between mobility service providers, public agencies, and public agency software partners. Although providers are often required to support MDS as part of mobility permits or policies, MDS is intended as a neutral mechanism for information exchange. It is not intended to force or foreclose any specific policy options that a public agency may choose to pursue. MDS is built as an interface between local governments and mobility service providers. Access to MDS APIs should be restricted, and is not intended to directly support public consumption or consumer-facing applications. ## Participation Policies and Code of Conduct + See our [CODE OF CONDUCT page](CODE_OF_CONDUCT.md). diff --git a/ReleaseGuidelines.md b/ReleaseGuidelines.md index 20090997..95c748c4 100644 --- a/ReleaseGuidelines.md +++ b/ReleaseGuidelines.md @@ -10,9 +10,12 @@ MDS will see regular updates and new [releases][mds-releases]. This document des * [Project Meetings](#project-meetings) * [Roles](#roles) * [Schedule](#schedule) + * [Approval by the Open Mobility Foundation](#approval-by-the-open-mobility-foundation) * [Communication and Workflow](#communication-and-workflow) * [Branch Mechanics](#branch-mechanics) -* [Checklist](#release-checklist) +* [Preparing a Release Candidate][prepare-rc] +* [Making an Official Release][make-release] +* [Hotfix Releases](#hotfix-releases) ## Versioning @@ -48,15 +51,16 @@ For now, MDS will maintain *two concurrent (MINOR) versions* (e.g. if `0.3.0` we Refer to the list of [Supported Releases](https://github.com/openmobilityfoundation/mobility-data-specification/wiki#supported-mds-releases) for more details. +[Top][toc] + ## Release Process + The sections below define the release process itself, including timeline, roles, and communication best practices. -> **The process defined below currently being piloted with the MDS `provider` API only. Proposed changes to the `agency` API will be continue to be reviewed on an ad hoc basis.** +### Project Meetings ->**It is our intent to maintain a level of coordination between the technical direction of `agency` and `provider`. As such, proposed changes to either API will be reviewed to ensure they do not create unnecessary duplicative functionality, introduce confusion about which API should be used for a given purpose, or prevent the reconciliation of data between the two APIs (for example: using data from `provider` to cross-validate data received via `agency`).** +* Web conference work sessions will posted to the [MDS-Announce mailing list][mds-announce] and on the [MDS wiki](https://github.com/openmobilityfoundation/mobility-data-specification/wiki). Each working group typically meets every two weeks. -### Project Meetings -* Web conference and in person work sessions will posted to the [MDS-Announce mailing list](https://groups.google.com/a/groups.openmobilityfoundation.org/forum/#!forum/mds-announce). Meetings generally occur monthly. * The meeting organizer can use the [meeting template](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-Conference-Template) to prepare for project meetings. Use the [template markup code](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-Conference-Template/_edit) to create the next scheduled wiki meeting page before the meeting. Include the how to join the meeting and agenda details. Posting the agenda before the meeting has the added benefit that project contributors can propose agenda items. ### Goals @@ -72,36 +76,58 @@ The sections below define the release process itself, including timeline, roles, * _Regular review of release process to ensure it is serving the needs of the community._ ### Roles + * **contributors** - Anyone making pull requests, opening issues, or engaging in technical discussion around implementation of features. + * **maintainers** - Project maintainers have commit privileges in the main MDS repository and are responsible for implementing changes such as merging of pull requests and the creation of release branches. -* **release partner** - Review changes when consensus cannot be reached and make final release inclusion recommendations to maintainers for approval. -As of March 2019, LADOT and the City of Santa Monica are the project maintainers and Remix is the release partner. +* **working group steering committees** - Review changes when consensus cannot be reached and make final release decision about what changes should be included in a release. + +See the [MDS wiki](https://github.com/openmobilityfoundation/mobility-data-specification/wiki) for additional information on the working groups. ### Schedule -MDS operates on a six-week release cycle for both major updates (0.x) and patches (0.x.y). In general, major updates (0.x) are expected no more than once per quarter. The release cycle is broken down as follows: +MDS operates on an approximately twelve-week release cycle for both major updates (0.x) and patches (0.x.y). In general, major updates (0.x) are expected no more than twice per year. The release cycle is broken down as follows: -**week 1 - proposals** +#### Weeks 1-3: Proposals Contributors submit proposals for inclusion in the release cycle in the form of pull requests and issues tagged. If known, note what release you intended a proposal for in its description. Maintainers will tag appropriate pull requests and issues with the Milestone for the upcoming release. Proposals should come with enough explanation to allow all stakeholders to understand intent and implementation strategy. -**weeks 2-4 - consensus building, refinement, and implementation** +#### Weeks 4-9: Consensus building, refinement, and implementation + +Contributors will provide feedback on proposals. Where possible, discussion will happen via GitHub. Weekly calls will support dialog around more complex or controversial issues. By the end of week 9, all active proposals must be in the form of a pull request. Proposals can be withdrawn or split apart for inclusion in future releases. + +##### Weeks 10-11: Decision making + +These weeks will start with an web conference work session for all contributors to review and discuss current proposals. Goal is to achieve consensus where possible, or to clearly articulate areas of disagreement where not. Minor changes may be accepted at this stage if they bring contributors to consensus. -Contributors will provide feedback on proposals. Where possible, discussion will happen via GitHub. Weekly calls will support dialog around more complex or controversial issues. By the end of week 4, all active proposals must be in the form of a pull request. Proposals can be withdrawn or split apart for inclusion in future releases. +During this period, the working group steering committees will review all items for which consensus was not reached and decide on a final release plan. Any remaining approved pull requests will be merged, and a maintainers or working group steering committees will open a pull request containing release notes for the proposed release. -**week 5 - decision making** +#### Week 12: Release -The week will start with an in-person/web conference work session for all contributors to review and discuss current proposals. Goal is to achieve consensus where possible, or to clearly articulate areas of disagreement where not. Minor changes may be accepted at this stage if they bring contributors to consensus. +Documentation will be updated, release notes will be merged and a tag will be created to point to it. At this point the new version will be formally considered a Release Candidate and begin the Open Mobility Foundation approval process described below. Subsequent sections describe how to [Prepare a Release Candidate][prepare-rc] and [Make an Official Release][make-release]. -At the conclusion of week 5, the release partner will review all items for which consensus was not reached and provide a recommended release plan to maintainers for approval. Any remaining approved pull requests will be merged, and a maintainer or release partner will open a pull request containing release notes for the proposed release. +### Approval by the Open Mobility Foundation -**week 6 - release** +Once a release is finalized by the working groups it will be considered a "Release Candidate" until it has been approved as an official deliverable by the Open Mobility Foundation. The OMF bylaws refer to this as a "Working Group Approved Deliverable (WGAD)." -Documentation will be updated, release notes will be merged, a tag will be created and `master` updated to point to it, and the new version will be formally released. See [Release Checklist](#release-checklist) for details about the release process. +The process for full OMF approval is detailed in Section 5.4 of the [OMF bylaws][omf-bylaws]. In summary: + +1. The release candidate/WGAD will be provided to the OMF Technology Council for review and comment at least 75 days prior to the desired date of board approval. + +1. The Technology Council will issue a report and/or recommendation for the Board of Directors within 60 days. + +1. The Board of Directors will have a minimum of 30 days to review the Technology Council recommendation before taking a vote on the release candidate/WGAD. + +1. Upon approval by the Board of Directors, the release will become an official deliverable of the OMF. It will be marked as such in GitHub and on the OMF web site, and it will be merged into the `master` branch on GitHub. + +The approval status and anticipated timeline will be reflected in the [MDS wiki](https://github.com/openmobilityfoundation/mobility-data-specification/wiki). While it is the intent of the OMF to have concerns, questions, and issues addressed during the regular working group release process, it is possible that the Technology Council or Board of Directors may request modifications to a release candidate/WGAD prior to official approval. If this situation occurs, the release candidate will be sent back to the working group(s) for additional changes after which it can be resubmitted to the Technology Council and Board of Directors. + +The OMF recommends that regulatory agencies do not formally adopt or require any versions of the spec that have not been fully approved by the OMF Board of Directors. However, release candidates/WGADs are considered stable enough to allow API producers and consumers to begin developing against in anticipation of formal approval. ### Communication and Workflow -The release announcements and process schedule will be communicated via [`mds-announce`][mds-announce] Google Group. People wishing to stay informed should join the group for updates. Timing of web conference and in person work sessions will be communicated via mds-announce as well. + +The release announcements and process schedule will be communicated via [MDS-Announce mailing list][mds-announce]. People wishing to stay informed should join the group for updates. Timing of web conference and in person work sessions will be communicated via MDS-Announce as well. The following best practices are intended to create clarity around each release cycle: @@ -113,162 +139,244 @@ The following best practices are intended to create clarity around each release * Proposed changes should come in the form of PRs to give the community ample awareness and time for feedback +[Top][toc] + ## Branch Mechanics -The branching strategy we describe here is intended to handle ongoing maintenance changes in parallel with features for new releases. +The branching strategy we describe here is intended to support ongoing maintenance changes in parallel with features for new releases. As mentioned earlier, MDS maintains two concurrent official MINOR releases. -### Primary branches +Generally there are two major categories of branches: *Long-lived* and *Short-lived*: -At a high-level, there are two primary branches: +### Long-lived branches -* [`master`][mds-master] represents the latest release of MDS. It's only updated as part of the release process, and no pull requests should be based on or target it. +There are always two primary long-lived branches: -* [`dev`][mds-dev] contains all work that has happened since the last release, including both breaking and non-breaking changes. +* [`master`][mds-master] represents the most recent official release of MDS. This branch is only updated as part of the release process, and pull requests should typically not target `master`. -### Feature branches +* [`dev`][mds-dev] is an integration branch for all work since the last official release, including both breaking and non-breaking changes. `dev` is where Release Candidates come from. -All development on changes to MDS should happen in branches cut from `dev` (with the exception of hotfixes to release branches, described below). When your work is ready for review, submit a PR against `dev`, ideally with any merge conflicts already resolved. `dev` serves as the collection point for all new feature work. +If a hotfix is required for a prior release (e.g. a hotfix on top of the `0.3.x` line when the current release is in the `0.4.x` line), a new long-lived *Support branch* will be created from the corresponding tag in `master`. *Support branches* are named according to the version line (e.g. `0.3.x`). -### Release branches +### Short-lived branches -Whenever a MINOR version is released, a **release branch** will be created from `dev` to track any changes that should be included in subsequent PATCH versions. For example, at the time `0.4.0` is released, a branch called `0.4.x` will be created that initially points to the same commit as the `0.4.0` tag. +There are two types of short-lived branches, both always branched from `dev`: -Release branches can be updated in two ways: +* *Feature branches* are for new feature work, which should be submitted as PRs against `dev`, ideally with any merge conflicts already resolved. Rebasing a *Feature branch* onto `dev` before submitting a PR is a great way to avoid lengthy and complicated reviews. Typically a *Feature branch* is created in a fork of the MDS repository. -* When a non-breaking change has been merged to `dev`, a maintainer will usually [backport](#backporting-changes) it onto the newest release branch. This can be skipped if the change isn't relevant to the release branch (e.g., because it modifies language that was added after the last MINOR release) or if there are no plans to make another PATCH release with the same MINOR version. +* *Release branches* are for preparing a new Release Candidate, and collecting any feedback before making an official release. A *Release branch* should be named like `release-x.y.z` where `x.y.z` is the intended version of the release. -* If a change needs to be made to spec language that exists in a release branch but is no longer relevant in `dev`, the contributor should create a feature branch based on the release branch and open a PR targeting the release branch directly. For example, if an endpoint was removed in `0.3.0` but needs to be modified for a `0.2.1` PATCH release, the contributor would create a PR based on the `0.2.x` release branch. +[Top][toc] -As stated earlier, at this time MDS will maintain *two concurrent MINOR versions*. This means that when a MINOR release is made (e.g. `0.4.0`), no further changes will be made to the outgoing series (`0.2.x`, in this case). +## Preparing a Release Candidate -### Backporting changes +The following steps outline the process to prepare a Release Candidate of MDS. This process makes public the intention and contents of an upcoming release, while allowing work on the next release to continue as usual in `dev`. + +1. Ensure the [Milestone][mds-milestones] for this release is at `100%`. -When non-breaking changes are merged to `dev`, it's generally necessary for a maintainer to backport these changes to the newest release branch so that they'll be included in any subsequent PATCH releases. There are a couple of different ways to do this: +1. Create a *Release branch* from the tip of `dev` named `release-x.y.z`, where `x.y.z` is the intended version of the release. This branch will be used to prepare the Release Candidate. For example, to prepare a Release Candidate for `0.5.0`: -* If the changes can be applied to the release branch without significant editing, the maintainer can use `git cherry-pick` to copy the changes from `dev` into the release branch (assuming the SHA of the merge commit on `dev` was `b70719b`): + ```bash + git fetch + git checkout origin/dev + git checkout -b release-0.5.0 + git push -u origin release-0.5.0 + ``` - ```console - git fetch - git checkout 0.3.x - git pull - git cherry-pick -m 1 b70719b - git push - ``` + Changes generated by the steps below should be committed to this branch. - Note that the `-m 1` option is unnecessary if the PR was merged with the "Squash and merge" option instead of creating a merge commit. +1. Update the [schema version regex][mds-schema-common]. -* If backporting the change needs significant manual work (for example, if there were other changes to the relevant part of the spec in the last MINOR version), the maintainer can open a new PR for the backport targeting the relevant release branch. +1. Run the schema generator to ensure the schema files are up to date: - First, create a branch containing the backported change (again, assuming the SHA of the merge commit was `b70719b`): + ```bash + cd schema/ + python generate_schemas.py + ``` - ```console - git fetch - git checkout 0.3.x - git pull - git checkout -b backport-helpful-change-to-0.3.x - git cherry-pick -m 1 b70719b - # Do any manual work needed to integrate the changes - git push -u origin backport-helpful-change-to-0.3.x - ``` +1. Update ReleaseNotes.md using the following format: - Next, create a PR with the release branch (in this case, `0.3.x`) as its `base`. Once that PR has been approved, merge the PR into the release branch as usual. + ```md + ## X.Y.Z + > Release Candidate submitted yyyy-MM-dd -## Release Checklist + High level summary of the release. -The following steps **must** be followed for **every** release of MDS: + ### CHANGES -1. Ensure the [Milestone][mds-milestones] for this release is at `100%`. + * Specific change referencing a PR [#555](https://github.com/openmobilityfoundation/mobility-data-specification/pull/555) -1. Update the [schema version regex][mds-schema-common]. + * Another change summary referencing a PR [#777](https://github.com/openmobilityfoundation/mobility-data-specification/pull/777) + ``` -1. Run the schema generator to ensure the schema files are up to date: +1. Create a tag like `x.y.z-rcN` for this Release Candidate. For example, for the first `0.5.0` Release Candidate: - ```console - cd generate_schema/ - pipenv run python generate_provider_schema.py - ``` + ```bash + git fetch + git checkout origin/release-0.5.0 + git tag 0.5.0-rc1 + git push --tags + ``` -1. [Open a PR][mds-pr-new] against `dev` that updates [`ReleaseNotes.md`](ReleaseNotes.md) using the following format: +1. Publish a [pre-Release in GitHub][mds-releases-new]: ```md - ## 1.2.3 + Tag version: [tag you just pushed] + Target: [release branch] + Release title: [X.Y.Z Release Candidate N] + Description: [copy in ReleaseNotes created earlier] + This is a pre-release: Check + ``` - > Released yyyy-MM-dd +1. [Open an Issue][mds-issue-new] to start the Release Candidate review process, using the `Release Candidate review` template. Fill in the appropriate Release Candidate version/URL. - High level summary of the release. +1. Post an announcement to the [MDS-announce Mailing List][mds-announce], copying the [release notes](ReleaseNotes.md) created earlier and linking to the [GitHub release][mds-releases] and Release Candidate review Issue: - * Specific change referencing a PR [#555](https://github.com/openmobilityfoundation/mobility-data-specification/pull/555) + ```email + From: mds-announce@groups.openmobilityfoundation.org + To: mds-announce@groups.openmobilityfoundation.org + Subject: MDS X.Y.Z Release Candidate - * Another change summary referencing a PR [#777](https://github.com/openmobilityfoundation/mobility-data-specification/pull/777) + A Release Candidate for MDS X.Y.Z has been submitted. + + [release notes] + + [link to GitHub pre-Release] + + The Release Candidate is now under OMF Review. Follow the progress here: https://github.com/openmobilityfoundation/mobility-data-specification/issues/XYZ ``` - The description of this PR should include a link to a GitHub compare page showing the changes that will be included in the release. This URL depends on the type of release: +### Incorporating feedback from OMF review - * For a PATCH release like 0.4.2, compare the previous version in the series to the current state of the release branch: https://github.com/openmobilityfoundation/mobility-data-specification/compare/0.4.1...0.4.x +The OMF review process may elicit further changes to a Release Candidate. Generally follow the same steps as above to prepare a subsequent Release Candidate, committing necessary changes to the release branch and incrementing the prior Release Candidate number where required. - * For a MINOR release like 0.5.0, compare the last release in the previous series to the current state of `dev`: https://github.com/openmobilityfoundation/mobility-data-specification/compare/master...dev +For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release][mds-releases-new] from there: - In the case of a new MINOR version, allow a minimum of 24 hours for community discussion and review of the current state of the release. +```bash +git fetch +git checkout origin/release-0.5.0 +# more commits per OMF review +git tag 0.5.0-rc2 +git push --tags +``` -1. Once the PR has been sufficiently reviewed, merge it into `dev`. +Communicate the new Release Candidate as usual, including in ReleaseNotes.md, on the MDS-Announce mailing list, and on the Release Candidate review Issue. Be sure to indicate that this is a *new Release Candidate* of the target version. -1. Create a tag for this release on the tip of `dev` (for MINOR versions) or the relevant release branch (for PATCH versions). For example, for `0.5.0`: +Repeat as-needed for subsequent Release Candidates. - ```console - git fetch - git checkout origin/dev +[Top][toc] + +## Making a Release + +The following steps describe how to make an approved [Release Candidate][prepare-rc] an official release of MDS: + +1. Ensure OMF review has been completed and the Issue created during the Release Candidate process has been closed. + +1. In the release branch created earlier, update the ReleaseNotes.md with the new date of the release: + + ```diff + ## X.Y.Z + + -> Release Candidate submitted yyyy-MM-dd + +> Released yyyy-MM-dd + + etc... + ``` + +1. [Open a Pull Request][mds-pr-new] from the release branch to `dev`. This ensures any changes to the Release Candidate during the review process make their way back into `dev`. Merge this PR. + +1. [Open a Pull Request][mds-pr-new] from the release branch to `master`. Merge this PR to make the release official. + +1. Create a tag in `master` for the new version. For example for `0.5.0`: + + ```bash + get fetch + git checkout master git tag 0.5.0 git push --tags ``` - Or for `0.4.2`: +1. Publish a [Release in GitHub][mds-releases-new]: - ```console - git fetch - git checkout origin/0.4.x - git tag 0.4.2 - git push --tags + ```md + Tag version: [the tag you just pushed] + Target: master + Release title: [X.Y.Z] + Description: [copy in ReleaseNotes created earlier] + This is a pre-release: DO NOT check ``` -1. If this release is a MINOR version, create a new [release branch](#release-branches). For example, if you've just created the `0.5.0` tag: +1. Post an announcement to the [MDS-announce Mailing List][mds-announce], copying the [release notes](ReleaseNotes.md) created earlier and linking to the [GitHub release][mds-releases]: + + ```email + From: mds-announce@groups.openmobilityfoundation.org + To: mds-announce@groups.openmobilityfoundation.org + Subject: MDS X.Y.Z Released + + MDS X.Y.Z has been released. + + [release notes] - ```console - git push origin 0.5.0:0.5.x + [link to GitHub pre-Release] ``` -1. Unless this is a maintenance release on an older branch (for example, releasing `0.3.2` after `0.4.0` has already come out), update `master` to point to the new tag: +1. Finally, delete the release branch. - ```console - git checkout master - git reset --hard 0.5.0 - git push --force origin master +[Top][toc] + +## Hotfix Releases + +In rare cases, a hotfix for a prior release may be required out-of-phase with the normal release cycle. For example, if a critical bug is discovered in the `0.3.x` line after `0.4.0` has already been released. + +1. Create a *Support branch* from the tag in `master` at which the hotfix is needed. For example if the bug was discovered in `0.3.2`, create a branch from this tag: + + ```bash + git fetch + git checkout 0.3.2 + git checkout -b 0.3.x + git push -u origin 0.3.x ``` -1. Publish a [new Release in GitHub][mds-releases-new] for the tag you just pushed. Copy in the [release notes](ReleaseNotes.md) created earlier. +1. Merge (or commit directly) the hotfix work into this branch. -1. Post a release announcement to [`mds-announce`](mailto:mds-announce@groups.openmobilityfoundation.org), copying the [release notes](ReleaseNotes.md) created earlier and linking to the [GitHub release][mds-releases]. +1. Update ReleaseNotes.md with the hotfix version details, following the existing format. - ```email - From: mds-announce@groups.openmobilityfoundation.org - To: mds-announce@groups.openmobilityfoundation.org - Subject: MDS 1.2.3 Release +1. For fixes that impact the current cycle (e.g. updates to language that still exists and hasn't been changed in the current cycle), [open a Pull Request][mds-pr-new] to merge the support branch back into `dev`. + +1. Tag the support branch with the hotfix version. For example if `0.3.2` is the version being hotfixed: - MDS 1.2.3 has been released. + ```bash + git fetch + git checkout 0.3.x + git tag 0.3.3 + git push --tags + ``` - +1. Create a [GitHub Release][mds-releases-new] from this tag and the support branch. For example if `0.3.3` is the new hotfix version: - + ```md + Tag version: 0.3.3 + Target: 0.3.x + Release title: 0.3.3 + Description: [copy in ReleaseNotes created earlier] + This is a pre-release: DO NOT check ``` +[Top][toc] + +[make-release]: #making-a-release [mds-announce]: https://groups.google.com/a/groups.openmobilityfoundation.org/forum/#!forum/mds-announce [mds-dev]: https://github.com/openmobilityfoundation/mobility-data-specification/tree/dev +[mds-issue-new]: https://github.com/openmobilityfoundation/mobility-data-specification/issues/new/choose [mds-master]: https://github.com/openmobilityfoundation/mobility-data-specification/tree/master [mds-milestones]: https://github.com/openmobilityfoundation/mobility-data-specification/milestones [mds-pr]: https://github.com/openmobilityfoundation/mobility-data-specification/pulls [mds-pr-new]: https://github.com/openmobilityfoundation/mobility-data-specification/compare [mds-releases]: https://github.com/openmobilityfoundation/mobility-data-specification/releases [mds-releases-new]: https://github.com/openmobilityfoundation/mobility-data-specification/releases/new -[mds-schema-common]: https://github.com/openmobilityfoundation/mobility-data-specification/blob/master/generate_schema/common.json +[mds-schema-common]: https://github.com/openmobilityfoundation/mobility-data-specification/blob/master/schema/templates/common.json [mds-tags]: https://github.com/openmobilityfoundation/mobility-data-specification/tags +[omf-bylaws]: https://www.openmobilityfoundation.org/resources/ +[prepare-rc]: #preparing-a-release-candidate [semver]: https://semver.org/ +[toc]: #table-of-contents