Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

r0.1.0 release of the Push Gateway specification #1521

Merged
merged 7 commits into from
Aug 30, 2018
Merged

r0.1.0 release of the Push Gateway specification #1521

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
ba51d59
r0.1.0 release of the Push Gateway specification
turt2live Aug 16, 2018
5b73a01
Clarify what the release branch is used for, and how it should be named
turt2live Aug 20, 2018
e141f61
Update release instructions to reference symlinks, what files to upda…
turt2live Aug 20, 2018
72c6fa2
More versioned links
turt2live Aug 28, 2018
b402608
Don't reference the major version for the push gateway specification
turt2live Aug 28, 2018
2ab2f91
Merge remote-tracking branch 'matrix-org/master' into travis/releases…
turt2live Aug 29, 2018
2a20c11
Take out the reference to the current version from the changelog
turt2live Aug 29, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 8 additions & 7 deletions meta/releasing_a_spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@ specification, server-server specification, and identity server specification. E
of these gets released independently of each other with their own version numbers.

Once a specification is ready for release, a branch should be created to track the
changes in. This should be the name of the specification (as it appears in the directory
structure of this project) followed by a forward slash and the version being released,
followed by `_updates`. For example, if the Client-Server Specification was getting
an r0.4.0 release, the branch name would be `client_server/r0.4.0_updates`.
changes in and to hold potential future hotfixes. This should be the name of the
specification (as it appears in the directory structure of this project) followed
by "release-" and the release version. For example, if the Client-Server Specification
was getting an r0.4.0 release, the branch name would be `client_server/release-r0.4.0`.

*Note*: Historical releases prior to this process may or may not have an appropriate
release branch. Releases after this document came into place will have an appropriate
Expand All @@ -21,12 +21,13 @@ The remainder of the process is as follows:
1. Update the changelog section of the specification you're releasing to make a reference
to the new version.
1. Update any version/link references across all specifications.
1. Update the index to list the version correctly.
1. Ensure the `targets.yml` file lists the version correctly.
1. Commit the changes and PR them to master.
1. Tag the release with the format `client_server/r0.4.0`.
1. Add the changes to the matrix-org/matrix.org repository (for historic tracking).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this happen after the rest of the process, so that r0.4.0 is tagged up before we update matrix.org?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a thing, yes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are some bear-traps in here waiting to ensnare the unwary, but the easiest way to find them is probably to try the process out and see what happened for real.

* This is done by making a PR to the `unstyled_docs/spec` folder for the version and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it needs latest symlinks too.

specification you're releasing.
1. Commit the changes and PR them to master.
1. Tag the release with the format `client_server/r0.4.0`.
* Don't forget to symlink the new release as `latest`.
1. Perform a release on GitHub to tag the release.
1. Yell from the mountaintop to the world about the new release.

Expand Down
2 changes: 1 addition & 1 deletion specification/modules/push.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -623,4 +623,4 @@ should send a "sync" command to instruct the client to get new events from the
homeserver directly.


.. _`Push Gateway Specification`: ../push_gateway/unstable.html
.. _`Push Gateway Specification`: ../push_gateway/%PUSH_GATEWAY_RELEASE_LABEL%.html