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

Re: Two further features, one definitely needed for survival, otherlikely needed.

From:
Achim Gratz
Date:
May 24, 2021 16:20
Subject:
Re: Two further features, one definitely needed for survival, otherlikely needed.
Message ID:
875yz8gl2i.fsf@Rainer.invalid
Nicholas Clark writes:
> On Sun, May 23, 2021 at 10:00:39PM +0200, Tomasz Konojacki 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.

Cygwin doesn't do this (and other rolling releases also don't offer
multi-version Perl).  I'll usually wait for the x.y.1 version to do a
full rebuild of everything that uses Perl and then update to the further
point releases without incurring that effort.  I've got to the point
where I could do an update including all Perl modules in Cygwin twice
within a day if I need to, but the other other maintainers with Perl
dependencies will have to update their packages as well (there is only a
single Perl version in Cygwin), making this a multi-week process in
reality.  I've only had one instance where I've had to revert something
to keep things binary compatible (the move of the interpreter variables
if anyone needs to know).  I know it isn't _guraranteed_ to work, but so
far I've been lucky and/or the release managers have been taking their
job seriously.

> Firms I've observed are even more conservative - they don't tend to
> backport *any* patches, treat an upgrade to x.y.z+1 or x.y+2.* with
> equal trepidation.

I'm witness to how that plays out in practise and anybody whose turn it
is to use the remaining brain cell in the IT department thinks that's a
stupid thing to do, not that they can change that situation.  None of
the vendors can agree what version that "single Perl" is going to be, so
in the end you have even more work to do; both while supporting the
current "official" Perl versions in their frozen (but slightly buggy)
state and when the dreaded time comes around that everyone decides they
need to update to a new set of incompatible versions.

[…]
> So we can't offer an stable ABI.

I hope you didn't want to say that the .z part of the versioning is
going to go away.  But if you stop making at least the promise that you
don't knowingly break ABI compatibility in minor releases then I'd
suggest you drop that part of the versioning to make it clear to
everybody what is going on.  Whether anyone left holding the bag will
pick up after that (what about security patches etc.) remains to be
seen.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables



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