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
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
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/