On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
Josh and I have been discussing plans for the upcoming release; below
is what we've come up with so far. This is loosely based on past 0.4x
plans. I'll follow up this email with explanations for the major
differences. Meanwhile, feedback would be appreciated.
# Period Tasks Notes
1. Open development.
2. Chill. Development focuses on wrapping up
3. Frost. Experimental Branch is forked B
Mainline Branch focuses on stabilization B
Only production-ready code committed to Mainline B
4. Feature Freeze. Stable Branch is forked from Mainline B
Regular development resumes on Mainline. B
Avoid major refactorings on Mainline. B
Only bug fixes committed to Stable Branch. B
Bug fixes are cherrypicked from Mainline. B
5. Hard freeze. Only Release Wardens can commit to Stable Branch B
Cherrypick bug fixes from Mainline to Stable B
6. Release. Post inkscape-0.91.tar.gz
7. Open development.
The branch strategy may seem a bit excessive, so let me explain the
thinking behind it.
The GSoC program has been great for Inkscape but it places some
constraints on when we can do releases. While GSoC is ongoing, many of
our key folks are busy mentoring, so coordinating a release can be
tricky. After it's completed, often the deliverables get integrated to
mainline and need time to stabilize. But we don't want to delay the
integration too long - ideally it's done during the summer while the
program is still ongoing and the student is still actively engaged with
it. Being able to deliver their branch to an "official tree" is often a
mark of accomplishment for the students.
Despite these challenges, since GSoC is a seasonal thing, we still can
schedule around it, with releases in winter or early spring.
But what about other sponsored development work, that might not follow
such a routine schedule? Several proposals have been floated recently
for kickstarter-ish efforts to fund development work. We definitely
want to encourage these types of efforts and enable them to have
successful deliveries. To do so we need to make the release process
So the idea here is to split off an official (but temporary)
Experimental branch. Not just the sponsored development work, but
really any efforts that are large, potentially disruptive, or otherwise
risky should be focused here.
During the whole Chill/Frost/Freeze process, Mainline focuses on
stability, with only bug fixes and production-ready features being
committed. We use an honor system for making commits, but also
encourage aggressive reverting of commits that prove to cause
The Stable Branch is established earlier in this plan than in past
release plans. It occurs at Feature Freeze rather than at Hard Freeze
in order to give more time for the final stabilization. The Stable
branch then can cherrypick fixes from Mainline as they're proven
Once the release is completed, the Stable branch can continue to
accumulate bug fixes towards .1, .2, etc. releases. At this point, the
Experimental branch (or pieces thereof) can be merged back to Mainline,
or we can hold off a bit, if we want Mainline to continue focusing on
stability for a bit. But eventually the Experimental branch will be
This Experimental / Mainline / Stable multiple branch strategy might
prove to be complicated, but it's an approach other projects have used
quite effectively. The main downside is that it takes a bit more branch
and patch management needed to keep the various branches coordinated.