module dependencies issues
rosuav at gmail.com
Thu Jul 9 23:20:16 CEST 2015
On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>> In general, I would expect that B 1.1 is backward-compatible with B
>> 1.0, unless otherwise stated. Why must it be declared in any way other
>> than the version number?
> To make it explicit. The generic component system shouldn't impose
> (m)any assumptions on version numbering. Version numbers can contain
> digits, punctuation, letters. Comparisons should be done the way "ls
> -v" and "sort -V" do it.
> Whoever creates B-1.1 ought to make it backward-compatible, but he
> should also say so. The majority of developers are careless about
> backward-compatibility; having the component system make wishful
> assumptions will lead to catastrophic consequences.
I strongly disagree. All your idea would do is create a massive
compatibility matrix, which would itself become utterly
unmaintainable. It's all very well to ask for a declaration that 1.1
is compatible with 1.0, but what happens when you add in 1.2 and 1.3,
and then add some point releases on all of them? Python 2.7 is up to
2.7.10; does every one of them need to declare backward compatibility
with every other, and with every point release of 2.6, and 2.5, and
how far back do we go? And just how compatible does it have to be to
get a tick? EVERY change can break someone's workflow - XKCD 1172
comes to mind - so does that mean that a single bugfix prevents the
compatibility mark? No. Version numbers exist to provide a granularity
to the compatibility concerns.
More information about the Python-list