Some projects work best with the mindset: "anything in main is already deployed. 'develop' is the dev merge target & the default branch".
Others work best with the mindset "main is the default merge target. Releases are deployed."
With the scale of npm packages being so small (vs some large npm-based projects like big websites) I think this project would benefit greatly from the reduced complexity of a basic release-based workflow. This is also the default "mode" that works well with the "GitHub flow". PRs default to merge against 'main', releases are made by admins/maintainers, automatic deployments happen on release; everyone's happy! 😊
We already seem to be halfway to the release-based "ideal" workflow, but right now there's some odd branches like "legacy"...
@mesqueeb Thoughts on this? I'd like to take the initiative and trim the branches back to simple main + feature branches and merge #78, but I want some kind of explicit 👍/👎 signal that I should or shouldn't do this.
mesqueeb
commented
1 week ago
Some projects work best with the mindset: "anything in main is already deployed. 'develop' is the dev merge target & the default branch".
Others work best with the mindset "main is the default merge target. Releases are deployed."
With the scale of npm packages being so small (vs some large npm-based projects like big websites) I think this project would benefit greatly from the reduced complexity of a basic release-based workflow. This is also the default "mode" that works well with the "GitHub flow". PRs default to merge against 'main', releases are made by admins/maintainers, automatic deployments happen on release; everyone's happy! 😊
We already seem to be halfway to the release-based "ideal" workflow, but right now there's some odd branches like "legacy"...
@mesqueeb Thoughts on this? I'd like to take the initiative and trim the branches back to simple main + feature branches and merge #78, but I want some kind of explicit 👍/👎 signal that I should or shouldn't do this.