Re: Release Maintenance Policy

Howard Chu <[email protected]> Sat, 7 Aug 2021 12:31:03 +0100
Newsgroups gmane.network.openldap.devel
Message-ID <[email protected]>
Quanah Gibson-Mount wrote:
> 
> 
> --On Friday, August 6, 2021 3:11 PM +0100 Howard Chu <[email protected]> wrote:
> 
>> Planning to post this to -announce soon, any comments?
>>
>>
>> Just a reminder to everyone: the Project has a long-standing policy of
>> doing active development on only one release version at a time. To
>> allow time for migrations we provide some overlap from one release
>> version to the next. E.g., while 2.5 is active we will still provide
>> critical bugfixes for 2.4. Since 2.4 has been around for something
>> like 14 years now people may have forgotten this policy.
>>
>> This is a heads up that with 2.6 due for release in September, all
>> updates to 2.4 will cease at that time. Likewise, when 2.7 is released
>> next year all updates to 2.5 will cease.
>>
>> Also for clarity: We consider "Critical" bugs to include security
>> flaws resulting in unauthorized data disclosure, or unauthorized
>> remote code execution. We do not consider assert() failures or crashes
>> resulting only in Denial of Service as security flaws.
> 
> That's fine as a general statement, but what we need is an explicit *documented* policy.  Likely under "Release Documents" here: 
> <https://www.openldap.org/software/>

Sounds like you should open a ticket against the website then.
> 
> Also, I'd like to see explicit terms here.  I.e., 2.4 is now in maintenance, which means only critical fixes are applied.  2.5 is active, which means it has an 
> active release schedule and is open for general bug fixes.  2.6 is in development which means that is where all new feature development and distruptive changes 
> are occurring.
> 
> As a part of that explicit policy and terminology, we need to provide some sort of time table on when a release moves from active to maintenance. Clearly it 
> would not have been fair to move 2.4 to maintenance the moment 2.5 released (for example we've done one non-security based release of 2.4 since 2.5 came out).

It would have been entirely fair. 2.4 has been around for 14 years and we had declared a feature freeze on
it long ago already. Doing a non-security based 2.4 release after 2.5 was released was an anomaly, one nobody
should rely on happening.


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/