On Wed, Apr 02, 2008 at 09:17:13PM -0500, Aaron Spike wrote:
rygle wrote:
I'm also thinking about a list of new features, and whether we should get them out for 0.46.1 or 0.47?
Traditionally only bug fixes have been backported from trunk to point releases. Features wait until the next full release.
Correct; there are a number of reasons for this, one of which is that we stand a better chance of getting the whole package accepted into Linux distros if we can show it to be a pure bug fix release, with all changes carefully tracked and documented.
From a Windows standpoint, there are a LOT of IT depts that will be
evaluating whether to accept the Windows version of Inkscape based on the quality of our .1 releases, and they also will prefer to see releases that are strictly carefully selected bug fixes. (I've also heard this from companies and one government, with interest in deploying Inkscape, that had this as a criterion).
A case in point - after the 0.45.1 release I worked to try to get it included into Ubuntu Feisty, but because we hadn't been sufficiently careful in tracking and itemizing the bug fixes, it didn't make it in.
The expectation I'm seeing from the above types of organizations is that only important bug fixes are included, and that for each fix:
* It solves a 'high-impact bug', such as any one of these: + Causes a security vulnerability + Severe regression from prior release + Can cause loss of user data + Causes failure to build on some platform + Causes segfault, crash, lockup, freeze, etc.
* Steps to reproduce the bug in the current inkscape release are given
* A patch is provided for review (svn revisions are okay... but a tangible patch is better)
* Discuss regression potentials. I.e., what is the risk level for causing side effects or breakage for other users? (For instance, if it fixes an OSX problem, is there risk of breaking on Windows?)
Some of the types of things that got kicked back in 0.45.1 were patches that were mostly code cleanups, "theoretical crashers" without steps to reproduce, cosmetic issues, feature tweaks/enhancements, etc. These may seem important to us, but distros and deployers may reject the update if there's too many of them.
Translation updates are a special category. They don't count as a 'high impact bug', however they have such low regression risk that they wouldn't count against adoption of a point release.
Bryce