On 5 January 2017 at 09:22, Bryce Harrington <bryce@...961...> wrote:
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.
As we already discussed earlier[1], one point is to create feature branches. This allows to keep the master branch stable (and by that releasable) and goes hand in hand with the GitHub and GitLab workflow of creating pull/merge requests. Another point, which you already mentioned, is to be more rigorous about last minute improvements. Let the team pick a few bigger features/changes and put them on the roadmap for the next release. There may be more features and changes, but they shouldn't block the release. Big changes like GTK3 or C++11 may stretch over several releases. Everything that comes too late for a release, simply needs to wait for the next one. And with a faster release cycle e.g. every few months, a feature that missed a release doesn't have to wait too long to get public.
Sebastian
[1] https://sourceforge.net/p/inkscape/mailman/inkscape-devel/thread/CAERejNYTv3...