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.