Front page | perl.perl5.porters |
Postings from May 2021
On Mon, May 24, 2021 at 12:52:56PM +0100, Niko Tyni wrote: > On Mon, May 24, 2021 at 10:21:37AM +0000, Nicholas Clark wrote: > > > It seems that even the work of trying to maintain binary compatibility > > *within* minor versions is mostly wasted. For any given version, OSes seem > > to stick on the exact x.y.z version that they started on, and then > > "backport" patches from our x.y.z+1 (etc) versions to their "x.y.z", > > without changing its "x.y.z", or relying on adding earlier versions to @INC. > > FWIW, Debian utilizes binary compatibility between minor versions during > development cycles, where it helps us quite a bit. The yearly rebuilds for > major releases are a big effort (mostly because herding all the packages > into a workable state at approximately the same time is a lot of work; > the actual recompiling itself is of course mechanical). Having to do > that for minor releases as well would increase our load quite a bit. I only use the "finished" distribution, and so I didn't know this. Thanks for the explanation. On Mon, May 24, 2021 at 04:27:52PM +0300, Sergey Aleynikov wrote: > пн, 24 мая 2021 г. в 13:21, Nicholas Clark <nick@ccl4.org>: > > > It seems that even the work of trying to maintain binary compatibility > > *within* minor versions is mostly wasted. For any given version, OSes seem > > to stick on the exact x.y.z version that they started on, and then > > "backport" patches from our x.y.z+1 (etc) versions to their "x.y.z", > > But breaking binary compatibility would make their work harder, not > easier. They'd need to either force-upgrade versions of all dependent > packages (to effectively rebuild them) or now they instead of us have > to review all patches for breakage. It doesn't look like a fair > exchange. Furthermore, that could lead to code running on 5.x.y on one > platform to have one set of not-fixed bugs, but running with a > different set on another platform - due to them choosing different > strategies. It's not impossible now, but foregoing binary in point > releases compatibility extravagets it. Sorry, I should have been clear. I wasn't proposing that we change the policy from what we have currently. Nicholas Clark