Re: Post 5.44 release plans: `defer-next-dev`
Sam Kington <[email protected]> Sat, 11 Jul 2026 00:21:15 +0100
| Newsgroups | gmane.comp.lang.perl.perl5.porters |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_C299E8A3-ACBD-4C63-A9B6-E083EC886C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Jul 2026, at 15:20, Paul LeoNerd Evans <[email protected]> = wrote: >=20 > On Mon, 6 Jul 2026 18:00:15 +0100 > "Paul \"LeoNerd\" Evans" <[email protected]> wrote: >=20 >> We have, at time of writing, 74 issues and PRs labelled >> "defer-next-dev". That's a great number larger than during any >> previous release. Previously we just bumped through them all after >> the real release once `blead` was open again for development work, >> but I feel that this time it may require a bit more co=C3=B6rdination = to >> ensure we don't get too many merge conflicts and allsorts. >=20 > Also on this note I think this situation is not something I'd want us > to get into every year. >=20 > I think it's bordering on ludicrous that we stop accepting any new > development work in February, and it's now July and we're still not > done. That's now 5 months out of the 12 in the year - almost half of > the time. >=20 > We need to find a better way around this. At a previous work where we did quarterly releases, we would typically = cut a release branch from the tip of the main branch, label it RC1, and = carry on development for the next release into the main branch. This was = fine, except that when we needed to fix stuff for the release, that = either (1) ideally fixed stuff in both branches, so stuff could be = cherry-picked cleanly, or (2) needed to be changed in two = subtly-different ways, because the dev branch had already marched ahead = of the release branch. Then I=E2=80=99d have to say, as release manager, = =E2=80=9Cplease solve the conflicts because I don=E2=80=99t understand = the code well enough=E2=80=9D. I suppose you could have a next-blead branch, cut from blead once we=E2=80= =99d decided that there was a code freeze for the next release. And once = perl 5.xx.0 shipped, you=E2=80=99d merge next-blead into blead, delete = the next-blead branch, and the perldelta for 5.xy.0 would look actually = interesting. But that would need someone to resolve the conflicts between blead and = next-blead, just after we=E2=80=99d cut a new release. Sam --=20 Website: https://www.illuminated.co.uk/ --Apple-Mail=_C299E8A3-ACBD-4C63-A9B6-E083EC886C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">On 9 Jul 2026, = at 15:20, Paul LeoNerd Evans <[email protected]> = wrote:<br><div><blockquote type=3D"cite"><br = class=3D"Apple-interchange-newline"><div><div>On Mon, 6 Jul 2026 = 18:00:15 +0100<br>"Paul \"LeoNerd\" Evans" = <[email protected]> wrote:<br><br><blockquote type=3D"cite">We = have, at time of writing, 74 issues and PRs = labelled<br>"defer-next-dev". That's a great number larger than during = any<br>previous release. Previously we just bumped through them all = after<br>the real release once `blead` was open again for development = work,<br>but I feel that this time it may require a bit more = co=C3=B6rdination to<br>ensure we don't get too many merge conflicts and = allsorts.<br></blockquote><br>Also on this note I think this situation = is not something I'd want us<br>to get into every year.<br><br>I think = it's bordering on ludicrous that we stop accepting any = new<br>development work in February, and it's now July and we're still = not<br>done. That's now 5 months out of the 12 in the year - almost half = of<br>the time.<br><br>We need to find a better way around = this.<br></div></div></blockquote></div><div><br></div><div>At a = previous work where we did quarterly releases, we would typically cut a = release branch from the tip of the main branch, label it RC1, and carry = on development for the next release into the main branch. This was fine, = except that when we needed to fix stuff for the release, that either (1) = ideally fixed stuff in both branches, so stuff could be cherry-picked = cleanly, or (2) needed to be changed in two subtly-different ways, = because the dev branch had already marched ahead of the release branch. = Then I=E2=80=99d have to say, as release manager, =E2=80=9Cplease solve = the conflicts because I don=E2=80=99t understand the code well = enough=E2=80=9D.</div><div><br></div><div>I suppose you could have a = next-blead branch, cut from blead once we=E2=80=99d decided that there = was a code freeze for the next release. And once perl 5.xx.0 shipped, = you=E2=80=99d merge next-blead into blead, delete the next-blead branch, = and the perldelta for 5.xy.0 would look actually = interesting.</div><div><br></div><div>But that would need someone to = resolve the conflicts between blead and next-blead, just after we=E2=80=99= d cut a new release.</div><div><br></div><div> <meta = charset=3D"UTF-8"><div>Sam<br>-- <br>Website: https://www.illumi= nated.co.uk/</div> </div> <br></body></html>= --Apple-Mail=_C299E8A3-ACBD-4C63-A9B6-E083EC886C41--