On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Chris Angelico <ros...@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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
