I agree with the tone of the preceding conversation that we need an explicit definition of “public” which includes all code which absolutely cannot be broken in patches, and in principle I think basing this on
Base at least) is a good idea, though I’m a bit apprehensive about whether the current set of
exported functions is sufficient.
I know I’m getting waaay ahead of things here, but I’ve given this some thought particularly as I have been quite involved with upgrading code for 0.6 to 1.0.
We really don’t want to be Python. At this point, it’s almost as if Python’s users are actively screwing its developers. I can’t tell you how many times I see something using Python2 and I say “Why is that on 2?” and they don’t even know. You can be sure much of that code (talking scripts now) is 3-incompatible when there was no real need whatsoever for it to be written that way. Most linux distributions, particularly Red Hat and Debian, still use Python2 as default. Worst of all, people who insist on using 2 occassionally have some justification for doing so as there seem to be a variety of (from what I can tell, poorly documented) performance regressions on 3. The package ecosystem is actually not too bad, most of the important stuff works fine on 3 (which is perhaps not saying much considering the amount of time 3 has been out), but regardless it seems the world is stuck with Python2 for all eternity. We should use this situation as a model of everything we want to avoid.
In my opinion at least 4 things are necessary not to wind up in that situation:
- We are going to have to be more conservative about breaking changes than we were during pre-release. I love how much effort went into polishing everything for 1.0 so that we are not stuck with silly choices for all eternity, but that was the last pre-release transition and we will never have quite that much freedom ever again. Breaking interface changes probably should occur only as parts of comprehensive re-works, and not “well, we just thought that was nicer” (as much as I personally like to change things based on that justification alone).
Compatis going to have to be really good. Let’s be honest, in a lot of places we kind of half-assed
Compatfor 0.6 to 1.0. I’m not knocking all the great work that was done, in some areas it actually was really polished. I am personally extremely guilty of failing to help
Compatbe better: I did a huge amount of work updating packages but I barely ever made any commits to
Compat. That’s because writing good
Compatcode is a really big pain, there are so many little gotchas. It was usually so much easier to just write some horrible hack into the package I was upgrading. That’s not going to be a good enough excuse for 2.0, it’s going to have to be really, really solid. I for one resolve to be much more helpful when that time comes.
- Benchmarks. If there are regressions, people won’t use your upgrades for good reasons.
- Really robust FemtoCleaner. Ideally, no human being should ever have to update code. I think we should aim to get as close to that ideal as possible. Considering the level of ambivalence-bordering-on-contempt I’ve seen in Python world, I really think this is the only thing that will truly save us.
Fortunately I think we are a large part of the way there. The basic components such as
FemtoCleaner have been with us since well before 1.0. We just need to make sure that we really take this stuff very seriously for 2.0, or Julia 1.0 will be the only version of Julia that most people ever use.