Changing the branch naming rule won't require more work for those who makes the release:
Now we: 1. add a tag with released version 2. create a branch for next version 3. mark it as main on github With this change we would: 1. add a tag with released version 2. create a branch for *released* version no 3, since next is always just 'main' 👍 On Sun, 30 Jun 2024 at 20:37, Trevor Gross via developers < [email protected]> wrote: > LLVM has a pretty good workflow for managing release branches with a > bot. PRs go to main by default, then a maintainer can `/cherry-pick > sha-or-range` with a sha from that merge (e.g. [1]) to have the bot > open a PR against the stable branch (e.g. [2]). This can then be > tested, approved and merged without anyone needing to do the work > locally. > > Something like this might be useful for MariaDB if a target branch or > branch range could be specified to get a PR against each branch: > `/cherry-pick 11.6 024a3122..4373c179` or `/cherry-pick lts..beta > 1f884c16’. > > Not to add any specific opinion here since adjusting release workflow > would be a huge change, but some automation would probably help smooth > things out if branches are ever refactored. > > - Trevor > > [1]: > https://github.com/llvm/llvm-project/pull/91776#issuecomment-2106751053 > [2]: https://github.com/llvm/llvm-project/pull/91917 > > On Fri, Jun 28, 2024 at 6:40 PM Eric Herman via developers > <[email protected]> wrote: > > > > I am glad to see this getting another look, as I've advocated for this > in the past. > > > > A cost to be considered is the change in workflow for those whom are > responsible for merging bug-fixes from the earliest branch up through all > of the still-supported releases and eventually on to trunk. > > > > While this cost of this change seems small to me, I'm not the one who > does this work; let's make sure that the maintainers who do this work are > well-supported as changes are made. > > > > Cheers, > > -Eric > > > > > > > > On Fri, 28 Jun 2024 at 22:23, Vicențiu Ciorbaru via developers < > [email protected]> wrote: > >> > >> I echo Nikita's position here. With our new model, a change that > happened once every year now must happen once every quarter. > >> > >> It would also map to our rolling release model too I believe. > >> > >> This was discussed in the past and we decided against it then, but now > times have changed where I believe it warrants a second look. > >> > >> Vicențiu > >> > >> On Fri, 28 Jun 2024, 16:58 Nikita Malyavin via developers, < > [email protected]> wrote: > >>> > >>> Hello Otto, > >>> > >>> I think it's a good idea, which improves the quality of life. > >>> > >>> The rebases will still have to take place, but at least the > contributors won't have to update the branch names in the PR! > >>> > >>> Regards, > >>> Nikita > >>> > >>> On Fri, 28 Jun 2024 at 05:55, Otto Kekäläinen via developers < > [email protected]> wrote: > >>>> > >>>> Hi! > >>>> > >>>> Has the core developers had discussions about using branch name 'main' > >>>> for development instead of switching to a new branch every 3 months? > >>>> > >>>> If all new features and other additions would always target the branch > >>>> 'main' it would lower the barrier of entry for new contributors, and > >>>> decrease the number of unnecessary rebases done by contributors. > >>>> > >>>> If the permanent development target was 'main', you would need to > >>>> create new 11.x branches only at "freeze" when a new major version > >>>> branch is cut for release. > >>>> > >>>> MariaDB is currently the only open source project I know that does > >>>> *not* have a main/master/trunk branch and instead does these constant > >>>> new branch names. I imagine this is not only annoying for > >>>> contributors, but also the core developers who waste time asking > >>>> contributors to rebase PRs every 3 months (see > >>>> https://github.com/MariaDB/server/pull/2556 and > >>>> https://github.com/MariaDB/server/pull/2671 as examples). > >>>> > >>>> - Otto > >>>> _______________________________________________ > >>>> developers mailing list -- [email protected] > >>>> To unsubscribe send an email to [email protected] > >>> > >>> > >>> > >>> -- > >>> Yours truly, > >>> Nikita Malyavin > >>> _______________________________________________ > >>> developers mailing list -- [email protected] > >>> To unsubscribe send an email to [email protected] > >> > >> _______________________________________________ > >> developers mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > developers mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > developers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Yours truly, Nikita Malyavin
_______________________________________________ developers mailing list -- [email protected] To unsubscribe send an email to [email protected]
