harpojaeger
commented
5 years ago I'm down with Github Flow instead of git flow. I'd vote for keeping the primary branch named main, for consistency with other forks.
Also agree that manual releases are the way to go now; to my mind, that means adding an explicit callout in the README that while main is best-effort stable, it's not necessarily safe to upgrade from any version to main at any given time. IOW if you want strict predictability about what will/won't break, wait for a tagged release.
I think we may not need a highly-formalized release process at the moment, since most of the changes we're looking at in the immediate future are related to refactoring, testing and developer experience. I'd very much favor bumping the version number for those, but I suspect it's enough to just say "well, we recently merged in a few new testing PRs; let's do a thorough round of manual QA and declare this to be v 1.4.2" or the like.
I haven't worked with conventional commits or semantic release in the past, but I'm down to implement at least the first one. One way of doing that is to mandate that all commits included in a PR follow the conventional commit spec. That seems hard to enforce. Another way is to always squash commits when merging a PR, which makes it easier to enforce naming conventions, but loses some commit history. I'd be happy with either of these options. I think semantic releasing might be more automation than a project of this size can handle right now, but I'd love to see us implement that in the future with a larger development community. For the moment, I think changelog entries can be enforced by PR reviewers, and as long as we're vigilant about making sure updates to the changelog include a detailed description of fixes/features/breaking changes & the name of the commiter, we'll have what we need to make versioning decisions at release time.
If you're satisfied with this, I'd say go ahead and open up a PR with any documentation or other changes you think are required to implement this.
jlegrone
bchrobot
Branching Model
I would like to propose that this fork of Spoke follow the "Github Flow" branching model:
https://guides.github.com/introduction/flow/
This is a simplified version of "git flow", which in my opinion is easier to reason about. We would only have one working branch named
master, and stable releases of Spoke would be indicated by semantically versioned git tags/Github releases.Release Process
Until more test automation is in place, and while Spoke continues to undergo very active development, I think it makes sense to continue manually creating releases.
The release process as documented by the Helm project may be something we could adopt without much modification:
https://github.com/helm/helm/blob/ead111dd4f699b3cb0a56f1e6d4585e3363f925b/docs/release_checklist.md
Changelog Generation
With more maturity around test automation, I do think it would be ideal to start releasing on a more regular cadence. I have had a lot of success in the past working with conventional commits and semantic-release for auto-generated releases and changelogs. While these tools make it much more sane to release on a frequent cadence, they also complement a more batched release process.
Adopting conventional commits would be a larger change for the project since it impacts contributors, though it is possible for maintainers to rewrite commit messages at the time of merge. It is also worth noting that there is great tooling out there for both generating and linting conventional commits, so adoption isn't quite as daunting as it may seem!
Semantic release does some other very cool things that make it worthwhile, like automating comments to Github issues and pull requests when a related release has been generated. This can be very useful to end users who have filed bugs and want to be notified when they're fixed!
For example: https://github.com/jlegrone/multi-env/pull/6#issuecomment-472277744