> On Jan 20, 2017, at 10:43 AM, Eric Covener wrote:
>
> On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr
> wrote:
>> Many if not most developers disagree with you, most developers agree that
>> adding features and enhancements is disruptive. 2.4.x adds features and
>> enhancements to every r
On Fri, Jan 20, 2017 at 5:27 PM, William A Rowe Jr wrote:
> On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener wrote:
>>
>> Maybe a [POLL] thread is in order, specifically for the topic of
>> enhancements/stability in 2.4 and ignoring aspirations about a new
>> versioning system or 3.0.
>>
>> e.g.
>>
On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener wrote:
>
> Maybe a [POLL] thread is in order, specifically for the topic of
> enhancements/stability in 2.4 and ignoring aspirations about a new
> versioning system or 3.0.
>
> e.g.
>
> 2.4.x is:
> [ ] evolving just fine
> [ ] too unstable due to new
On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr wrote:
> Many if not most developers disagree with you, most developers agree that
> adding features and enhancements is disruptive. 2.4.x adds features and
> enhancements to every release, and is therefore not low-risk, and absolutely
> not "as l
On Thu, Jan 19, 2017 at 5:49 PM, Jacob Champion wrote:
> This is somewhat orthogonal to Bill's current suggestion. It solves a
> different set of problems, more related to the short-term
> features-versus-regressions argument and less related to the long-term ABI
> arguments. Both are important to
On Fri, Jan 20, 2017 at 8:07 AM, Graham Leggett wrote:
> On 20 Jan 2017, at 2:15 AM, Jacob Champion wrote:
>
>> Ignore the versioning number then; that's not really the core of my
>> proposal. The key points I'm making are
>>
>> - introduce the concept of a low-risk release line
>
> We have alwa
On 20 Jan 2017, at 2:15 AM, Jacob Champion wrote:
> Ignore the versioning number then; that's not really the core of my proposal.
> The key points I'm making are
>
> - introduce the concept of a low-risk release line
We have always had this, the current low-risk release line is called v2.4.x.
On 20.01.2017, at 02:00, Eric Covener wrote:
>
> On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion wrote:
>> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line.
>> There are no new features or large code changes to this branch, there are no
>> refactorings or whitespace ch
On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion wrote:
> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line.
> There are no new features or large code changes to this branch, there are no
> refactorings or whitespace changes or huge cleanups; the only changes that
> land h
On 01/19/2017 04:25 PM, Stefan Sperling wrote:
On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote:
We branch off from the 2.4.25 tag.
I am not sure you mean this literally, but anyway:
I mean that the 2.4.25.x branch starts from the commit that we tagged as
2.4.25. That's all. (
On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote:
> We branch off from the 2.4.25 tag.
I am not sure you mean this literally, but anyway:
While basing a branch off of a tag (svn copy ^/tags/foo ^/branches/newbranch)
works, I would recommend to always create a branch first, and then
On 01/19/2017 03:57 PM, David Zuelke wrote:
Please no .micro releases. Most of the world is now trying to stick
to http://semver.org principles.
I agree with you, actually, but as you know, httpd is not on SemVer
currently and I'm not sure we can get there before 3.0. Maybe we'll all
agree on
I can even imagine a world where that makes sense...
Please no .micro releases. Most of the world is now trying to stick to
http://semver.org principles.
Why not just keep 2.4 for maintenance, and start working on 2.6 immediately? Or
2.5?
I honestly think that the current "odd numbers are unstable" approach is not
helpful with this whole situati
14 matches
Mail list logo