--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
19 matches
Mail list logo
