> I'm also not clear are we talking about git tags here or github > labels? We are using git tags but that is when we cut the release on > the release branch.
I don't know why I assumed Github labels and not git tags. I was obviously talking about Github labels. I'm not sure how David sees the use of git tags in this context. For backporting PRs, I don't mind either solutions, but I also prefer periodically adding the PRs with the backport prefix and the PR number. I guess others had some concerns with this, maybe they can help us understand. On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <bash...@brennanashton.com> wrote: > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche > <abdelatif.guettou...@gmail.com> wrote: > > > > > Would tags do the same thing? > > > How does this work over time? > > > Many PRs or keep force pushing to the PR > > > > For each release there will be only one PR that hosts all the > > backported commits. > > And yes, tags would work I guess, it's easy to filter PRs with tags on > > Github. > > > > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back > > > ported commits. > > > > We did something similar for PRs in the last release. Is the purpose > > to be able to filter out the backported commits later? > > I liked what we did last release with periodically adding a PR with > the backported commits. If we just keep one giant PR with the > backports this will make it harder for people to test the branch. > For the most part we had the backported PR numbers in the PR title > which made it really easy to match up later to figure out what did not > apply to the next release. I don't really have an opinion on the > matter of if we edit the commit, but I am not sure what the added > value would be. > > I'm also not clear are we talking about git tags here or github > labels? We are using git tags but that is when we cut the release on > the release branch. > > --Brennan
