[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Karen Shaeffer]

On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote:
> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote:
> 
> As Chris said, the only thing preventing this is manpower. But if there are people ready and willing to do this, then I don't see it as a Bad Thing.
> 
> My first comment is that these should be strictly bug fix releases. So your (1) above wouldn't include changes other than bug fixes. There would need to be a hierarchy for bugs. The reason is that *any* change to the stable branch inherently carries risk. So for instance, a bug that's a crasher, but would affect only a small number of people may not be worthy of inclusion into a dot-release. Etc.
> 
> My second comment is that top-of-tree moves very fast. This can make changes hard to back-port to a stable branch that may be months old. You are stuck having to either do it yourself, or begging the original author to back-port the fix. :-)
> 
> How frequently do you expect to do a dot-release? Our major release schedule is roughly every 6 months. Do you think bimonthly would be too many? or would you do it only when enough changes require it?
> 
> Finally, there is testing to consider. Obviously, full testing would be too rough on the community; people simply don't have enough time to spend a full month testing a dot-release. What are you thoughts on how testing would proceed?
> 
> -bw

Hello folks.

I believe the best policy for maintenance release dates should be driven by the need to fix a
critical bug. If you do a major release and a critical bug is found in the first few weeks, then
a maintenance release should happen in that time frame. Maintenance releases are not scheduled
by the calendar but by the needs of the users relating to known bugs. If you do a little research
on the linux kernel maintenance releases, you'll see a clear pattern, where there are typically
several patch releases in the first month, and the rate of patches exponentially declines rather
quickly. I would expect the same of any complex code base.

enjoy,
Karen
-- 
Karen Shaeffer
Neuralscape, Mountain View, CA 94040