With 0.92.0 now in the rear-view mirror (amazingly!) it's a good time to look at places we could improve.
Overall I think it went quite well. Switching build systems was a big change, and getting two year's worth of feature work stabilized is quite an achievement.
Based on the feedback I'm seeing, it looks like we made a very good choice to retire our OSX packaging. I admit I was a little worried, but suv's judgment was 100% right, and as anticipated our deliberately *not* providing it is stimulating others to step in and fill the void. With 0.93 on Gtk3 it sounds like we'll have opportunities for even better OSX packages.
Release management often is a tough trade-off between staying on schedule vs. delaying to allow pulling in last minute improvements. We did a fair bit of the latter, which looks like it is paying off nicely, but it did result in a quite long release cycle. I feel bad at having to say 'no' so much these last few weeks, I hope no hard feelings! But I suspect to achieve faster releases we're going to need to be more rigorous here. I would love to hear good ideas on how we could achieve that.
Part of the delay was that the CMake conversion took rather longer than I had anticipated. I suppose that's the nature of volunteer projects, and is going to hold true for most big changes we need to undertake. Something we'll need to keep in mind when updating the roadmap. All that said, cmake does seem to be working out for the most part. I figure we'll need to revisit this again later (I'm starting to see some strong buzz about a build system called Meson), but should stick with cmake for the time being. We've got other big infrastructural changes pending which now need are full attention.
Another big part of the delay was blocker bugs. I found this very hard to get my hands around; the issues are legitimately troublesome problems that should be resolved, but finding people able and available to work on them was tough. Unfortunately bugs are inevitable, and I worry the shift to Gtk3, C++11, and so on are destined to give rise to more. Does anyone have ideas on how we can handle things better so there are fewer blockers? Or ways to get the blockers resolved more quickly?
Compared with the above two issues, the actual technical mechanics of rolling out a release are trivial, however there is significant room for improvement. Compared with other projects I do release management for, Inkscape's process is a bit too manual and has a number of extraneous steps. There are some opportunities for automation once we move to git, and simply dropping autotools/btool/etc. will eliminate having to manually edit a bunch of different files to set version numbers. In the future where there are files that require setting version numbers or whatnot, instead of adding manual steps to the release process, what I want people to do is add a configure_file() function call to our 'dist' logic that substitutes the new release version number. (I'm looking at you, .snapcraft.yml.)
By now, we've done so many releases we have the release process down to a bit of a science, and we have ample checklists and todo lists. We know quite precisely what needs to be done and when. But where we ran ran into trouble was getting those tasks assigned out and completed on schedule. Thankfully, everything ended up getting done - kudos to everyone that stepped up and pitched in! But far too often they got done only after deadlines had passed; in some cases this caused schedule targets to get postponed, in other cases it caused impacts elsewhere such as translation. Mainly I blame myself - ultimately these are all failures in performing good release management. But some how or other we need to tighten all of this up if we are going to get releases out in a more timely fashion. Does anyone have suggestions or observations that could help us improve this?
Finally let me say, "Great work!" Because at the end of the day we've done it - put out a solid release with some awesome features and a good deal of attention to QA. A common theme I'm seeing in comments is the huge positive impact Inkscape has made in people's lives and careers, and the 0.92 release you've created is going to enable a lot of people to do some really great things.
Bryce