Some quick thoughts based on recent Twitter conversations about Python version support in OSS projects, presented in (ironically, given the topic) lazy bullet list format.
- Open source project maintenance exists along a continuum whose primary differentiator is basically “effort”.
- On the low-effort end is “release code and nothing else”. No documentation, no tests, no promise it runs on anything but what the author developed it on. This is the bare minimum: the effort needed to actually write the code.
- The high end is hard to quantify (there’s always something else one could do to make things better for users) but basically means one has extensive, well organized documentation; 100% code coverage; supports a large number of runtimes (e.g. for Python, something like 2.2 through 3.4 is rare but theoretically doable); etc.
- As with every continuum, most projects are in the middle, with some docs, some tests, and maybe supporting more than one runtime (though many only support one.)
- Exactly where on the slider one falls depends on many factors: amount of time/effort/manpower available; value judgements on which aspects of maintainership are worthwhile; value judgements re: various tradeoffs.
- For example, some projects feel that tests are more important than docs, and will prioritize in that direction, including up to “we don’t need docs, the tests are self-documenting.” (This position is wrong for a number of reasons, but the overall “if we have to choose, tests are better” viewpoint has validity.)
- Or (and this was the focus of the Twitter discussions) one may argue that
supporting older interpreters is/is not worth the pain of skipping newer
syntaxes or libraries. My opinion is that it’s a balance between userbase
size and a quantification of that pain.
- For example, my opinion is that Python 2.5 is no longer worth supporting for projects wishing to also support Python 3: a combo 2.5-3.x codebase is significantly harder to achieve than a combo 2.6-3.x one; and only a tiny fraction of users are on 2.5 (c.f. this data from @dstufft and also this even more recent data).
- Conversely, while 2.6 is less popular than 2.7, it is still nontrivial (~30% of Python users remain on 2.6, going by the above links) and the benefits of dropping 2.6 support are nowhere near as large for a 2+3 project as that of dropping 2.5. Ergo 2.6 support is valuable.
- If, instead, 2.7 did add a significant amount of 3.x compatibility, or if 2.6 had, let’s say, <10% userbase, then the argument for dropping 2.6 would be stronger.