Release automation and keeping up project momentum #4025
Comments
|
CC'ing the reviewers and maintainers: @milosgajdos @chrispat @clarkbw @corhere @deleteriousEffect @heww @joaodrp @justincormack @squizzi @sargun @wy65701436 @SteveLasker @dmcgowan @stevvooe @thaJeztah @Jamstah |
|
What would we consider to be supported targets for security updates? (https://github.com/distribution/distribution/blob/main/SECURITY.md) Would we support 3.0 after release of 3.1? |
|
Since there would be no breaking changes between Now arguably I'm not sure if this approach is water tight and many projects to create release branches for minor versions. However, this might be because they aren't following proper SemVer (which is extremely common). Now I'm not sure what all the pros and cons are of branching only for major versions compared to for minor versions as well and am happy for input here. What I do know is that supporting branches for minor versions will increase the burden of maintainers a lot and require a bunch more automation. Since the goal here is to help get the pace of the project up and keeping it there I'm biased towards the solution with the least maintenance overhead. However, once we have a solid group of active maintainers and regular releases the situation is completely different and having release branches for minor versions might make a lot of sense. |
I kinda like the approach |
|
Having a closer look at some of the semantic release documentation here, it actually confirms what I thought we could do going forward. We can create the branches for minor versions from the existing version tags as we need to release fixes on top of minor versions. Scenarion:
This way we can still use the |
|
Are we planning for beta/rc releases? How do they work? |
We should do. We have done that in past, but how theyre supported and how they work was never properly "codified" so we should discuss that. |
|
I'll need to do some testing with the automation I've described above to see how it ends up working exactly. Then I'll also play around with beta/rc releases. For |
|
I appreciate the proposal, and it's important for us to establish a concrete release cadence.
Additionally, we should define a process that includes beta, RC and GA. |
|
I think it's worth getting a beta release up ASAP even if it's not fully automated, then we can tell dependent projects about it |
|
Yes, we should kick things off for Going forward I think the monthly release cycle makes sense to me 🤔 Personally, I'd prefer RCs only in scenarios that introduce some new behaviour or major b/w compatibility breakage kinda thing. Otherwise we should stick to semver releases 🤔 |
|
I'll give this a more thorough read, but one quick comment;
I really prefer NOT to do this. Github's squash commits are... rather bad;
|
|
I agree with @thaJeztah, I am also against squashing commits. We can always ask explicitly for squash on a PR if need be. |
|
Then we'd need to find another way to enforce conventional commits for all the commits of a PR. Which can be a pain for contributors since rewriting a commit message is less easy than changing a GitHub PR title. I'm not against it though, just need to look into how to enforce it. I hope to get something setup for this this week or early next week. |
@wy65701436 Major releases would only be created for breaking changes, not for new features and enhancements. Those are what minor releases are for. For a setup like this to work we need to be strict with enforcing SemVer, and Semantic Release helps us with enforcing SemVer strictly. |
|
Conventional Commits would go a long way to enforce SemVer, but it relies on the author and reviewers to not make any mistakes. Tooling like https://pkg.go.dev/golang.org/x/exp/cmd/gorelease would help catch unintentional breaking API changes before it makes it into a release. |
|
Good suggestion. We should be able to layer that on top of conventional commits and run it in an action on PRs to check if a PR makes breaking changes. |
Yes, revise my comments, should be minor as item1 and patch for item2 |
Background
It's no secret that the project hasn't been the most active in terms of releases. It's my opinion that the slow and unpredictable release cycle is also partly responsible for the slow momentum of the project and contributions. To solve this, I would like to propose a fully automated release cycle so that contributors know when their improvements will be included in a release and maintainers don't need to manually plan and execute each release.
The setup
Default to pull request titleso that the commits merged into the repo follow the the Conventional Commit specification. See below for the setting for the repo.This allows us to publish new versions of
distribution/distributionin a fully automated fashion with the release versions conforming to proper SemVer and no need for manual intervention.Repo setting for only allow squash merges:
Open points for discussion
Naturally a change like this brings up a lot of discussion points. Here are a few that I'd like to bring up. However, none of these should be blocking for the initial implementation for the automation.
Release cadence
Having a high release cadence can be a chore for users of the software. Releasing quarterly I feel might not keep the project momentum as high as releasing monthly, but it is also a good option instead of monthly. While it would be possible to release a new version every day, week or for each new commit, since this project is used by big services as part of their infrastructure I don't believe this is a good choice.
Branching structure
The choice of how we want to create release branches for back porting fixes has a big influence on how our PR workflow will look and how Semantic Release needs to be configured. For some background information I highly recommend reading this documentation for Semantic Release.
Currently we are creating branches for minor versions (e.g.
release/2.7,release/2.8). When following proper SemVer, minor versions shouldn't introduce any breaking changes. As such, I'm not sure we would need to create branches for minor versions going forward (this should also reduce the maintenance burden somewhat, also taking errors with Semantic Release into account). Personally I think we should only create branches for new major versions.This also brings up the discussion about what the default release branch should be. Taking the upcoming
v3release as an example I think there are 2 setups to consider:mainbranch is and remains the release branch forv3going forward. This means contributors can simply target the main branch to add their improvements for the current release. This also mean we don't need to setup a bunch of automation to merge changes from main into release the branch(es). For any breaking changes, they would target the branch namednext. Before mergingnextintomainfor thev4release, a branch forv3is created for continued support and fixes.v3release av3release branch is created. All contributors wanted to add improvements to the current release would need to target that branch. Themainbranch would then again be used for the next major release (similar tonextfrom option 1). We'd need to setup automation for merging any minor and patch commits from themainbranch into thev3release branch.To avoid the current situation where the
mainbranch has diverged enormously from the current release branch (which in my opinion seriously hinders the momentum of the project), my preference is for the first option. This should also significantly reduce the burden for maintainers, remove the need for additional complex automation workflows and be more transparent for contributors.The text was updated successfully, but these errors were encountered: