On 04/14/2016 09:21 AM, Jeroen Demeyer wrote: > A really important point (which so far hasn't been addressed) is how to > deal with breakages of affiliated packages. I see two ways: > > 1. If I make a change to some core package, it is my responsibility to > ensure that no affiliated package breaks. > > 2. It is the responsibility of the affiliated package to fix breakages. >
It would be have to be (2), and that would be the distinction between an affiliated package (one that depends on Sage) and one that gets added to Sage itself. Both should still be an option: people get less upset if they make a choice and it bites them in the ass than they would get if you forced the same choice (that they would have made anyway) on them. Breakages will still occur, but they can be managed. If it becomes possible to package Sage without all of third-party software, then it becomes possible for the people who depend on Sage to depend on a particular version (and enforce that with pip, or a package manager, or whatever). That's not possible now because Sage hasn't been packaged most places. Then all we need is a little discipline to not break things too badly between releases. To do that, we have to figure out what the "public API" is, and how much we're allowed to change it. Major versions (e.g. sage-6.x to sage-7.x) should be "anything goes." With the current versioning scheme, minor releases should be things like build-system changes, method additions, bug fixes, and dependency updates. (This needs more careful thought than I've given it.) The release manager would have to decide which is which, and maintain two separate branches. The current "develop" branch corresponds to "the next major release", and we would need a new branch for "the next minor release" containing only those tickets that don't break the public API. Nobody can write code depending on a library that is guaranteed to work forever with all versions of that library. But "anything can change at any time" isn't much of a promise to those people. Having a more semantic versioning scheme will make things a lot less painful. And the option to commit straight into Sage itself is there for the people who are willing to give up some control for stability. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
