New “time since last post” high score! At this rate I’ll end up blogging once a decade š° Some quick updates today, including a moderately sized Paramiko announcement.
New “time since last post” high score! At this rate I’ll end up blogging once a decade š° Some quick updates today, including a moderately sized Paramiko announcement.
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.
Just a quick note that there is now a roadmap section on my projects page. I’ll be linking to this from the project websites ASAP.
My hope is that this goes a small way towards addressing the thing where my reduced cadence makes it look like projects are “dead” when they’re actually just sleeping (cue Monty Python parrot reference here).
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.
The next round of Paramiko releases is now out on PyPI, including – as previewed here – 2.0!
For some time now, plans to switch Paramiko’s crypto backend from PyCrypto to PyCA’s Cryptography have been in motion. (Sometimes, slow-motion. Sorry.) These efforts are drawing to a close, and because they represent a nontrivial change in install dependencies – even though there aren’t any public API changes – we’re going to call the result Paramiko 2.0.