no release branches

[tomdavidson]

Our implementation of trunk based workflow does not have release branches, but tags from the single long-lived branch, main.

How does auto work with the base branch and prerelease branch both being main?

What do we need to do in order to release with out release branches?

thanks

[sugarmanz]

Hey @tomdavidson! Thanks for your question. This is actually similar to the intended usage pattern for Auto! Merges to main will trigger a release and tag main. Canary builds (non-tagged, but published prereleases) are done with normal PRs and tagged prereleases are done with a next branch that you can stage changes on until they're ready for release. If you want to actually publish prereleases off main, you'll need to ensure you're calling the right auto command, i.e. auto shipit for releasing and auto next for prerelease. But since your workflow is already very similar to the ideal workflow for Auto, I would encourage you to consider publishing prereleases from a staging branch that would get released on merge.

[tomdavidson]

@sugarmanz thank you for the quick response and I am quite excited about putting auto into play. I thought I was going to need to use the exec plugin and what not but seem like the case is not that different at all.

Diffidently do not want another merge branch or my Gerrit friends will make fun :D seriously, I think multiple merge branches are a counter-productive pattern. A successful CI against main can end with auto next and when we feel like we want to promote an actual release, we can checkout that git tag and run auto shipit ?

We could prob even have a workflow that cuts the release after 10 days of no bug reports or something.

[sugarmanz]

Of course! Yeah, the exec plugin might seem like an easy backdoor to do what you want, and it is, but it does get complicated quick. Might I ask what type of project you're trying to use Auto for? (NPM, Maven, Gradle, etc.)

A successful CI against main can end with auto next and when we feel like we want to promote an actual release, we can checkout that git tag and run auto shipit?

This wouldn't really work because Auto will generate commits on release, for updating changelog, modifying version file, etc. So, checking out the branch and trying to run auto shipit would essentially result in those commits not being able to written to main because the tip of main contains commits not on the tag.

So, either you have to create a release branch from that tag (which you said you don't want to do), or you have to run auto shipit from the tip of main, however, this would end up releasing everything on main.

I think generally, our rule of thumb is that what is on main should represent the latest release. I think it would probably be okay to run auto next on main, but the only way releases on main would work then is if everything on main gets released when auto shipit is executed.

Alternatively, you could always just use the PR canary builds for testing and pre-release purposes. Even after merging, those builds should still be available. Then whenever you're confident that main is stable, you can perform your release on main. Part of the reason we value staging branches is so that we can ensure that main is always stable by testing our prereleases from the staging branches before merging.

[tomdavidson]

Thanks for explicit and illustrated explanation!

Seems like the only sticky point is promoting an rc (next) as a release.This does have code change if only the changelog so, but it would be better to promote the existing proven artifact rather than building a new one. I need to think about how this could work with GH Actions and Auto and appreciate any additional suggestions. Quite committed to the single trunk.

Right now I only have npm targets in the repo with lerna. We have some related Docker images and Crates that I want to be in the same repo but it would be ok to have the three target types in separate works spaces.

[hipstersmoothie]

Right now auto doesn't support that #917