Repository navigation
Proposal/Question: Release frequency #3067
Description
First, I must say that the project is nice and quite useful and the contribution experience is smooth: Local testing is made easy, and the contributing guide is clear. So many thanks to maintainers!
Just a comment though: when a contribution is accepted, it's taken into account quickly, but release frequency is quite slow.
So, as "go-github" consumers, people have to use "snapshots" for a while if the change is needed.
What about performing a release automatically for each change made?
While performing the PR, it could be useful to identify if it's a fix, a new feature or a breaking change.
This way, while merging, it would be possible to automatically create a patch, a minor release, and a major release.
I'm motivated to contribute to this or anything else if you're interested in it!
Activity
gmlewis commentedon Feb 9, 2024
Thank you, @chapurlatn . If you search for the word "release" in this repo's issues, you get 4 pages of results, so this is not an uncommon topic of discussion. In fact, I originally made releases after almost every merge.
First off, I would like you to read this message from the original author of this repo:
#1280 (comment)
and I would like to hear your thoughts.
At one point, we decided to release approximately monthly or on-demand-as-requested, which is what I've been attempting to do.
chapurlatn commentedon Feb 13, 2024
Hey @gmlewis,
Sorry for the "nth" message :-( You're right, I thought I have taken a look at issues about release but after several other search and reading, I think my brain gave up ;-)
I will participate to the issue.
himazawa commentedon Feb 14, 2024
Honestly I would prefer a release cycle based on conventional commits.
For this purpose release-please could be useful.
We use
go-githubin production, having new major releases just for minor or fixes that are not breaking changes could be an issue.gmlewis commentedon Feb 15, 2024
I'm not sure that I understand that statement. In this repo, we have never bumped the major release number without a breaking API change to my knowledge and we weren't proposing we do that, either.
OK, so we have two votes for release-please with conventional commits.
With 10k stars, 2.2k forks, and 211 watches, I'll wait for a bit more consensus before attempting this non-trivial undertaking.
More comments and/or thoughts on this issue are welcome.
himazawa commentedon Feb 16, 2024
You are right, the current release cycle is good IMHO, except for the fact that we are skipping minor fixed that may be needed by someone.
I just added that if you want to change it you should follow a standard. e.g. a release cycle based on semver, with the help of conventional commits.