On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
Hi all,
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
- Open development.
- Chill. Development focuses on wrapping up
- Frost. Experimental Branch is forked B Mainline Branch focuses on stabilization B Only production-ready code committed to Mainline B
- 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
- Hard freeze. Only Release Wardens can commit to Stable Branch B Cherrypick bug fixes from Mainline to Stable B
- Release. Post inkscape-0.91.tar.gz
- 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 more flexible.
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 regressions.
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 necessary.
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 EOL'd.
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.
Bryce