develooper Front page | perl.perl5.porters | Postings from May 2021

Re: binary compatibility between minor releases

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
May 24, 2021 13:34
Subject:
Re: binary compatibility between minor releases
Message ID:
20210524133423.GD16703@etla.org
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About