Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 30, 2017 at 7:17 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
> On Sat, Jul 01, 2017 at 12:45:51AM +0200, Björn Persson wrote:
>> Adam Williamson wrote:
>> > Clearly what I meant was "any future non-backwards-compatible major
>> > Python release". Maybe *right now* you don't expect there to be one,
>> > but I'm sure there was probably a point during Python 1's lifetime at
>> > which no-one expected there to be a backwards-incompatible Python 2,
>> > and a point during Python 2's lifetime at which no-one expected there
>> > to be a backwards-incompatible Python 3...
>>
>> Spot on.
>>
>> There is a Swedish proverb. I don't know whether an English version
>> exists, but in translation it is: One time is no time; two times is a
>> habit. Since the Python API has been broken twice, we can expect that
>> it will be broken again.
>
> "Fool me once, shame on you; fool me twice, shame on me"?
> But in this case both parties are one and the same, so "Fool myself
> once, shame on me; fool myself twice, shame on me again" which does
> not come quite as well ;P

It's also not an attempt to "fool" people, and it's a quite familiar
problem. It's inevitable with any language or program toolkit that
uses community published modules, and a core toolkit that is evolving.
It's happened with Java, with Ruby, with Perl, and even way back with
X11, which used to be X10. (Yeah, I'm that old!) It's not feasonable
to declare the core completely static and invulnerable to incompatible
upgrades. Heck, I remember when the "mod_perl" module  did a major
upgrade that was *completely* incompatible with the old versions and
insisted, *insisted* on not updating the major release number.

In this case, there are many Python modules that are only lightly
maintained, and whose current dependencies are not available in older,
structurally distinct versions of Python. It's been effective, and
reasonable, to maintain a distinction in the package names and to
allow SRPM's to compile *both* versions at the same build time, which
they do quite effectively. This also helps keep the tool available for
alternative default python builds for Fedora, for EPEL, for
backporting to RHEL, and even for integration to other repositories
like Red Hat's Software Collections Library. That doesn't make it
critical to Fedora, but it makes it useful to quite a few Fedora
contributors whose email address includes '@redhat.com'. Let's be
sensitive to compatibility support for people who are very active in
developing Fedora.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux