Don’t let the title scare you; I’m not going anywhere in particular. But the last ~year has seen a couple of big changes that I wanted to briefly share.
Don’t let the title scare you; I’m not going anywhere in particular. But the last ~year has seen a couple of big changes that I wanted to briefly share.
If you haven’t heard by now, the Freenode IRC network is under new, bad, management. I’m locking my channels there and will be registering my project names over on Libera.Chat.
Long story short: I’m finally starting to drop Python 2 (and a few slightly older Python 3s) from my projects, in a phased manner. Background and details follow.
A quick followup to my previous missive.
is admitting you have a problem; so with that in mind:
Hi. My name’s Jeff, I maintain several OSS projects you may be familiar with1, and I’m burned out.
I lie awake at night, unable to sleep, crippled by guilt. During the day, it’s anxiety and fear that cripple instead, making the thought of facing the issue tracker unbearable.
Development on my projects has slowed far more than I ever intended, and while I have excuses2, push has clearly come to shove. Something must change.
When it comes to software maintenance tradeoffs, most of what I laid out in “The why & when of software releases” remains accurate. An ‘iron triangle’ exists between speed, stability, and ease of maintenance – it’s impossible to prioritize all three.
I historically prioritize stability, specifically via bugfix-oriented release branches – users can stick to a given minor version even after subsequent feature releases appear, with the implied contract that they can install updates from those branches without anything breaking.
But as I’ve burnt out, I lean more towards ease of maintenance (at least when push comes to shove) though I still do my best to backport fixes anytime it’s easy enough.
Today’s post is about a specific conflict between stability and ease of maintenace, as seen in my efforts to drop Python 2.6 and 3.3 support from Paramiko.
Paramiko 2.0 came out in spring 2016, heralding a switch of crypto backend from PyCrypto to Cryptography (though no API incompatibilities were introduced). At the time, my commitment to Python 2.6 was still firm, despite slowly decreasing support elsewhere.
By late 2017, the combination of a vastly shrunken 2.6 user pool and similarly decreased ecosystem support (in Cryptography especially) finally prompted me to drop it too, in Paramiko 2.4. However, because of the stability promise, I couldn’t extend this cut to 2.0-2.3.
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.
A bunch of notes about Paramiko, Fabric and Invoke, such as their websites, their Python 3 support, and more! With copious exclamation points!
Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.
However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.
Life has continued to conspire against me, but this particular Friday I successfully wrested some time from other responsibilities and put out a couple of releases.