[cdwg] Lustre maintenance releases

[Nathan Rutman]

On Jul 17, 2012, at 10:47 AM, Christopher J. Morrone wrote:

> On 07/17/2012 07:46 AM, Andreas Dilger wrote:
>> On 2012-07-17, at 4:42, Peter Bojanic <peter_bojanic at xyratex.com> wrote:
>>> On 2012-07-17, at 03:55 , John Carrier wrote:
>>>> A colleague asked if OpenSFS had considered the Linux kernel model of alternating even numbered feature releases with odd numbered stable maintenance releases.
>>> 
>> 
>>> Back to the future! Lustre 1.2, 1.4, 1.6, and 1.8 were the stable production releases, reserving the odd numbers for development releases. The practice was decidedly dropped as of Lustre 2.0.
>> 
>> I wasn't necessarily fond of that decision, but at the same time Linux has dropped the "even means stable" convention as well and is just using 3.1, 3.2, 3.3, ... release numbers, and some of them are picked up for longer term stable releases (usually in line with vendor kernels like 2.6.32), others not.
>> 
>>>> If we apply this model to your proposal (18m maintenance releases, 3y total support for each maintenance branch), then we would need to reduce the number of feature releases to just one, 9months after the maintenance release.   Is that too long between releases? Does this model prevent additions of new features in the odd numbered releases?
>> 
>> There will still be new features included in each release (whether slated for long term maintenance or not). The difference is that after the designated maintenance release is made, it will continue to get bug fixes over time.
>> 
>> I wouldn't object to going back to the even/odd convention if this helped people to distinguish between the releases. However, I don't think this should be a driver for when and how the releases are made.
>> 
>> If we wanted 2.3 as a feature release, and 2.4 as a maintenance release it would work out fine, though we can't retroactively change 2.1. For later releases we could skip the even numbers until it was time for a maintenance release, like 2.5, 2.7, 2.8, then 2.9, 2.11, 2.12 or 3.0 (depending on how major the features are, e.g. exascale stuff).
>> 
>> Cheers, Andreas
> 
> I agree.
> 
> I think there are lots of possibilities for making the numbering more understandable, and for better explaining them to the community.  But we should make the numbering scheme fit a development model, not try to change development to fit a numbering scheme.
> 
> On the question of making the feature-release cadence nine months, my feeling is that is a bit too long.  Although I guess that opinion isn't very strong.  I believe that the current six month cadence is working fairly well, and I haven't heard anyone suggest that the current six month schedule is too short, so I would tend to prefer that we leave that part of the process unchanged.

I agree, the cadence seems to be working and Peter Jones at WC is keeping things on track - if it ain't broke...