https://www.runatlantis.io/ logo
Join Slack
Powered by
This message was deleted.
# atlantis-contributors
s
This message was deleted.
l
In this case I ask because I have some work I'd like to do that "builds off" this PR, but also I'm interested in general
d
only 
fix
PRs/commits are cherry picked back into the 
release-x.y
branches. Patch releases will be tagged and based on those branches as well
feat
are never cherry-picked and only show up on new 
release-x.y
branches when a new minor/major version is released.
l
ok so the goal of commenting "cherry-pick release-x.y" is to say "whenever this gets merged into main, make a new PR that merges it back into the release branch"?
👍 1
With the assumption the release branch already exists so would be "behind" main?
ah ok cool that makes sense. So in this example, the PR still needs to be merged into 
main
, but once it is, it will "automatically" merged into 
release-0.27
p
but it needs linear history to work
otherwise the bot does not create the pr
l
ah interesting. Anything we can do on a contributor side to make that smoother? Or is that just a "release time" issue?
d
I am going to make some docs today around what to do if the bot fails to PR which happens when there is a merge commit instead of a rebase on the PR, like Pepe said.
👍 1
@Luke Massa I made some docs with our GOVERNANCE update https://github.com/runatlantis/atlantis/blob/main/CONTRIBUTING.md#backporting-fixes
l
ah I see yeah that clarifies things considerably
I guess my only remaining question, mostly out of curiosity: when do the maintainers create a 
release-x.y
branch? Presumably it's cut from 
main
, so everything that was in main before that moment "gets in", and everything else must be explicitly and intentionally added to that release?
d
you create a branch on a major/minor release. Yes it is cut from main
that way we explicitly only backport fixes to keep the branch as stable as possible from future features
that was our biggest problem was the noise from releases trying to fix one thing and breaking another
l
Yeah totally
how do you decide when to cut the branch? I assume before it was just, there came a time when you wanted to do a release and you made a tag
now cutting the release branch can (and I assume does?) happen well before the decision that it's time to "do" the release
d
its done in the same time just right before
we do a quick sweep of PRs 
waiting-for-review
to make sure things are in before cutting
and then the GH release will tag for us
l
ah cool cool
2 Views
Open in Slack
PreviousNext
Powered by