--On Wednesday, January 29, 2020 10:09 PM +0100 Michael Ströder
wrote:
On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
wrote:
On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
Also, I really really really would like 2.4.49 to
On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
> wrote:
>
>> On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
>>> Also, I really really really would like 2.4.49 to be the end of 2.4,
>>> outside the possibility of some critical CVEs.
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder
wrote:
On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
Also, I really really really would like 2.4.49 to be the end of 2.4,
outside the possibility of some critical CVEs.
But that's just your personal goal which is leaving sys
On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote:
> Also, I really really really would like 2.4.49 to be the end of 2.4,
> outside the possibility of some critical CVEs.
But that's just your personal goal which is leaving systems in
production unpatched until you feel you're done. IMO that's totally w
On Wed, 29 Jan 2020 at 05:46, Quanah Gibson-Mount wrote:
> But my point was, I think it’s a fallacy to tie software quality and
> frequency of releases.
I encounter way too much software today that
> releases frequently, but what it releases is poorly (or not at all) QA'd,
> etc. And it's a nigh
--On Tuesday, January 28, 2020 7:01 PM +0100 Michael Ströder
wrote:
Today releasing is already way too slow. And I'm concerned that a
release policy with additional constraints, as suggested with
odd-/even-numbered releases, will make it even harder to get important
fixes out of the door.
On 1/28/20 6:30 PM, Quanah Gibson-Mount wrote:
> --On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
> wrote:
>
>> On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
>>> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
>>> wrote:
>>>
On 1/27/20 10:19 PM, Quanah Gibson-Mou
On Mon, Jan 27, 2020 at 02:17:13PM -0800, Quanah Gibson-Mount wrote:
> No, not at all. I would say OpenLDAP has too few releases in a year (only
> 1-2 currently for most years, unfortunately), so having more frequent
> releases for it is probably a good thing. But a piece of software in
> general
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder
wrote:
On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
wrote:
On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
To me, frequent releases
generally indicate an immat
On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote:
> --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
> wrote:
>
>> On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
>>> To me, frequent releases
>>> generally indicate an immature, unstable, and buggy product. ;)
>>
>> Are you sarcastic her
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder
wrote:
On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
To me, frequent releases
generally indicate an immature, unstable, and buggy product. ;)
Are you sarcastic here?
No, not at all. I would say OpenLDAP has too few releas
On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote:
> To me, frequent releases
> generally indicate an immature, unstable, and buggy product. ;)
Are you sarcastic here?
Ciao, Michael.
--On Saturday, January 25, 2020 11:22 PM +1100 Hugh McMaster
wrote:
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
> 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.
This is also one of the massive de-motivators as a developer. Creating
something that solves a problem and sits unused
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-
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 tr
On Fri, Jan 24, 2020 at 08:12:49AM -0800, Quanah Gibson-Mount wrote:
Starting with OpenLDAP 2.5, the OpenLDAP project will use a new
release process.
Odd numbered releases will contain only bug fixes
Even numbered releases will allow for minor new features
Works for me. Similar to Gavin's not
>> Constructive responses to the new release strategy welcome.
>
>
> Sounds good! Although odd numbers seems to feel like something risky, i.e. a
> new feature, whereas even numbers feel nice and comfy, boring and just bug
> fixes. Maybe just me!
How does that fit with https://semver.org/ ?
===
> Odd numbered releases will contain only bug fixes
> Even numbered releases will allow for minor new features
>
> This will allow for end users who want stability to focus on odd numbered
> releases while allowing those who need/want newer features to be able to
> make use of them.
>
> Constructiv
There's been ongoing discussion about making changes to the current release
strategy with OpenLDAP.
Traditionally we've (for the most part) kept new features out of the
release branch and did our best to primarily focus on bug fixes only. There
have clearly been exceptions when warranted (such
20 matches
Mail list logo
