[Linux-ha-dev] Re: [Linux-HA] Heartbeat Release Strategy

[Andrew Beekhof]

On Feb 9, 2007, at 2:38 PM, Max Hofer wrote:

> Hi Andrew,
>
> Thanks for pointing out the new release schema.
>
> On Monday 29 January 2007 19:30, Andrew Beekhof wrote:
>> Good morning sports fans.
>>
>> Over at Heartbeat Central we've been talking and have decided to do
>> releases a little differently from now on.
> If have a question.
>
> Would it possible to have a long-time-release (LTR). This would be a
> Feature (Minor) Release choosen by you (or whoever is coordinating
> the project).

<gratuitous_plug>
If you purchase a Novell/SUSE support contract then I'll be forced to  
provide you with such bugfixes for a number of years :-)
</gratuitous_plug>

That said, I understand many people can't/won't run SLES for various  
reasons, so there is some merit in your request.

However, I'd like to see how the proposed arrangement works out first  
before committing to anything else.

2.1 (when it comes out) should still be receiving updates until at  
least the end of the year.  Perhaps at that time it will be apparent  
that Current+LTR is a better alternative than Current+Previous.  On  
the other-hand, if the number of required bug-fixes is few then  
Current+Previous may be plenty for people.

>
> The LTR would not get any new features but just backports of
> bugfixes from future minor releases.
>
> The point in making such LTR is to avoid major changes in running
> systems. So admins would try and stick to a LTR and decide to
> upgrade minor versions of the LTR only if really needed.

Understood.  That was the starting point for the proposal I made.
However there needs to be a balance between this and the reality that  
we're only really paid to work on the current version (unless there  
is a SLES support contract involved of course :-)

>
> Clairly it would make no sense to define too many LTR (each 5
> minor releases? .. only a suggestion).
>
> Is there a way to track down bugfixes on the current source? I mean
> a clean separation of "this patch is a new feature" or "this is a  
> bugfix"?

Anything related to a Novell or OSDL bugzilla entry includes the bug  
number in the commit message.

>
>> With that in mind, it is our intent that this is what you can expect
>> from the Heartbeat team:
>>
>> Architectural (aka. Major) Releases:
>> * Contents:    		Architectural changes
>> * Frequency: 		As required but hopefully not often
>> * Supported Version:	Current and previous (for a limited period)
>> * Release Criteria:	5000 CTS Iterations of a 4 node cluster or
>> equivalent^
>>
>> Feature (aka. Minor) Releases:
>> * Contents:		New features + bug-fixes
>> * Frequency:		Three releases per year
>> * Supported Versions:	Current and previous
>> * Release Criteria:	5000 CTS Iterations of a 4 node cluster or
>> equivalent^
>> * Notes:
>>    - The timing will probably be March, July and November
>>    - We may at times decide to skip a feature release, in such cases
>> we will make
>>      an annoucement to this effect
>>    - Each feature release will have its own (numbered) Hg repository
>> on http://hg.linux-ha.org
>>
>> Bug (aka. Point) Releases:
>> * Reason:		Urgent bug-fixes and/or new resource agent scripts
>> * Frequency:		Monthly (providing there are bug-fixes pending release)
>> * Supported Versions:	Current only
>> * Release Criteria:	1000 CTS Iterations of a 4 node cluster or
>> equivalent^
>> * Notes:
>>    - No new features
>>    - If no new bugs have been fixed we'll just make an announcement
>> explaining
>>      this and not put out a release.
>>    - Each bug release will be a tag in the Hg repository of it's
>> Feature release
>>    - If every month becomes too much overhead for me, we may move to
>> bi-monthly releases
>>
>> ^  eg. an 8 node cluster would need somewhere in the order of 50%
>> less iterations to perform an equivalent workload
>>
>>
>> So, given all that, it is my hope that come March we will be able to
>> put out 2.1.0 and from then on follow the above strategy.  We will
>> then review this approach every so often to ensure it is still
>> appropriate.
>>
>> regards,
>> Andrew