Hugh McMaster wrote:
> On Sat, 25 Jan 2020 at 06:48, Ryan Tandy wrote:
>> Why was this particular approach chosen? As opposed to, for example,
>> doing feature releases more often (e.g. 2.6 as soon as a few months
>> after 2.5), or adding a fourth version component (2.5.y.z) for strictly
>> bugfix-only patch releases? Not trying to advocate a change of decision,
>> just interested in the thought process...
> 
> For what it's worth, I'm also interested in the thought process behind
> the decision.
> 
> As an observer of this project, the length of time between releases in
> this project makes it seem far less active than other projects.
> 
> So, I personally would like to see more frequent releases, with a
> clearer timeline and goals for each release.
> 
> Of course, developer time, motivation and other factors come into
> play, so it's not cut and dry.
> 
> Just my two cents.

As an open source developer I would prefer to have new features released 
immediately.
But as a provider of commercial support, we find that our customers are 
reluctant to
deploy anything with significant changes; they prefer stability. Over the past 
7+
years we've catered too much to their need for stability, resulting in many new 
features
sitting only in git master, unreleased for years. This new strategy is an 
attempt to
prevent new features from languishing unreleased for so long, while still 
providing for
the more stability-sensitive parties out there.

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

Reply via email to