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 release-please releaser action #66

Merged
merged 2 commits into from
Sep 20, 2022
Merged

ci: add release-please releaser action #66

merged 2 commits into from
Sep 20, 2022

Conversation

stigok
Copy link
Contributor

@stigok stigok commented Sep 7, 2022 •
edited
Loading

@stigok stigok requested a review from a team as a code owner September 7, 2022 13:00
@joberget
Copy link
Contributor

joberget commented Sep 7, 2022

@stigok any doc on this?

umglurf
umglurf previously approved these changes Sep 7, 2022
View reviewed changes
Copy link
Contributor

@umglurf umglurf left a comment

Choose a reason for hiding this comment

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

hvorfor ikke bruke semantic-release?

@stigok
Copy link
Contributor Author

stigok commented Sep 7, 2022 •
edited by umglurf
Loading

hvorfor ikke bruke semantic-release?

Fordi den ikke støtter v0 releases semantic-release/semantic-release#1507

@stigok
Copy link
Contributor Author

stigok commented Sep 7, 2022

@stigok any doc on this?

I have updated the PR description with a link

@umglurf
Copy link
Contributor

umglurf commented Sep 7, 2022

hvorfor ikke bruke semantic-release?

Fordi den ikke støtter v0 releases semantic-release/semantic-release#1507

I think this is good enough for v1 now, better to use the common release system than running something different here

@stigok
Copy link
Contributor Author

stigok commented Sep 7, 2022 •
edited
Loading

hvorfor ikke bruke semantic-release?

Fordi den ikke støtter v0 releases semantic-release/semantic-release#1507

I think this is good enough for v1 now, better to use the common release system than running something different here

I disagree. We should first sort out any breaking change in the issue list before going v1. We can also change releaser action once we hit v1 (or rather, right before), if we deem it a better fit.

This is also a good chance to see if the release-please workflow might work better for this sort of project, where we don't necessarily want a new release for every new commit merged into the default branch.

@stigok
ci: add release-please releaser action
137baf0
@stigok
ci: set initial release as v0.14.0
437a946 
The count of `feat` commits up until now determined this number. Better
than starting at 0.1, since it is more mature. Maybe better than than making
one up.
@stigok stigok merged commit edc3832 into main Sep 20, 2022
@stigok stigok deleted the ci-add-release-please branch September 20, 2022 07:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@umglurf umglurf umglurf left review comments

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

Successfully merging this pull request may close these issues.
3 participants
@stigok @joberget @umglurf