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

Jump to bottom

ci: add new release process using release-please #1391

Merged
merged 1 commit into from
Feb 2, 2024
Merged

ci: add new release process using release-please #1391

merged 1 commit into from
Feb 2, 2024

Conversation

hf
Copy link
Contributor

@hf hf commented Feb 1, 2024 •
edited
Loading

Adds a new release process based on release-please.

As soon as this gets merged, releases will work as follows:

  1. PR merges will be collected by release-please into a release PR. The team at Supabase decides when a release is ready to go out, usually weekly or bi-weekly.
  2. Every PR merge (that uses feat: or fix: titles) will result in a release candidate release with tag rc<version>. Example: if the new release will be 2.140.0 then the RC release will be rc2.140-rc.1, and so on.
  3. Once the release PR is merged, an official release will be published with the tag v<version>, or per the example v2.140.0.
  4. Releases with a patch version of 0 get a special branch release/v2.140.0 which can be used to patch that and only that major+minor version, using the same process as above.

For an illustration, check this repo where I used to test the script: https://github.com/hf/gotrue-release-please-test

@hf hf requested a review from a team as a code owner February 1, 2024 16:53
@hf hf merged commit e56944f into master Feb 2, 2024
2 checks passed
@hf hf deleted the hf/release-please branch February 2, 2024 08:41
@hf hf mentioned this pull request Feb 6, 2024
Merged
hf added a commit to supabase/auth-js that referenced this pull request Feb 7, 2024
@hf
ci: add new release process based on release-please (#849)
847b0a5 
Adds a new release process based on
[release-please](https://github.com/googleapis/release-please).

As soon as this gets merged, releases will work as follows:

1. PR merges will be collected by release-please into a release PR. The
team at Supabase decides when a release is ready to go out, usually
weekly or bi-weekly.
2. Every PR merge (that uses `feat:` or `fix:` titles) will result in a
release candidate release with tag `rc<version>`. Example: if the new
release will be `2.140.0` then the RC release will be `rc2.140-rc.1`,
and so on.
3. Once the release PR is merged, an official release will be published
with the tag `v<version>`, or per the example `v2.140.0`.
4. Releases with a patch version of `0` get a special branch
`release/v2.140.0` which can be used to patch that and only that
major+minor version, using the same process as above.
5. RC releases are tagged `rc` in NPM and regular ones as `latest`.
Patched releases get the label `patched`.

Similar to:
- supabase/auth#1391
uxodb pushed a commit to uxodb/auth that referenced this pull request Nov 13, 2024
@hf
ci: add new release process using release-please (supabase#1391)
d0b0b1f 
Adds a new release process based on
[release-please](https://github.com/googleapis/release-please).

As soon as this gets merged, releases will work as follows:

1. PR merges will be collected by release-please into a release PR. The
team at Supabase decides when a release is ready to go out, usually
weekly or bi-weekly.
2. Every PR merge (that uses `feat:` or `fix:` titles) will result in a
release candidate release with tag `rc<version>`. Example: if the new
release will be `2.140.0` then the RC release will be `rc2.140-rc.1`,
and so on.
3. Once the release PR is merged, an official release will be published
with the tag `v<version>`, or per the example `v2.140.0`.
4. Releases with a patch version of `0` get a special branch
`release/v2.140.0` which can be used to patch that and only that
major+minor version, using the same process as above.

For an illustration, check this repo where I used to test the script:
https://github.com/hf/gotrue-release-please-test
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 13, 2024
@hf @LashaJini
ci: add new release process using release-please (supabase#1391)
3cf3c65 
Adds a new release process based on
[release-please](https://github.com/googleapis/release-please).

As soon as this gets merged, releases will work as follows:

1. PR merges will be collected by release-please into a release PR. The
team at Supabase decides when a release is ready to go out, usually
weekly or bi-weekly.
2. Every PR merge (that uses `feat:` or `fix:` titles) will result in a
release candidate release with tag `rc<version>`. Example: if the new
release will be `2.140.0` then the RC release will be `rc2.140-rc.1`,
and so on.
3. Once the release PR is merged, an official release will be published
with the tag `v<version>`, or per the example `v2.140.0`.
4. Releases with a patch version of `0` get a special branch
`release/v2.140.0` which can be used to patch that and only that
major+minor version, using the same process as above.

For an illustration, check this repo where I used to test the script:
https://github.com/hf/gotrue-release-please-test
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 15, 2024
@hf @LashaJini
ci: add new release process using release-please (supabase#1391)
1668662 
Adds a new release process based on
[release-please](https://github.com/googleapis/release-please).

As soon as this gets merged, releases will work as follows:

1. PR merges will be collected by release-please into a release PR. The
team at Supabase decides when a release is ready to go out, usually
weekly or bi-weekly.
2. Every PR merge (that uses `feat:` or `fix:` titles) will result in a
release candidate release with tag `rc<version>`. Example: if the new
release will be `2.140.0` then the RC release will be `rc2.140-rc.1`,
and so on.
3. Once the release PR is merged, an official release will be published
with the tag `v<version>`, or per the example `v2.140.0`.
4. Releases with a patch version of `0` get a special branch
`release/v2.140.0` which can be used to patch that and only that
major+minor version, using the same process as above.

For an illustration, check this repo where I used to test the script:
https://github.com/hf/gotrue-release-please-test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kangmingtay kangmingtay kangmingtay approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@hf @kangmingtay