Am 26.01.2017 um 00:20 schrieb David Zuelke:
On 20.01.2017, at 21:37, Graham Leggett wrote:
On 20 Jan 2017, at 7:47 PM, David Zuelke wrote:
I'd actually like to question the whole practice of porting features back to
older branches. I think that's the
On 20.01.2017, at 21:37, Graham Leggett wrote:
>
> On 20 Jan 2017, at 7:47 PM, David Zuelke wrote:
>
>> I'd actually like to question the whole practice of porting features back to
>> older branches. I think that's the core reason why trunk is in total
>>
On 20 Jan 2017, at 10:40 PM, Jim Jagielski wrote:
> In fact, I'd announce 2.5-alpha "immediately" as what's
> in trunk... with a set schedule that 2.6-Beta1 is tagged 2
> months later and a goal that 2.6-GA be announced at
> ApacheCon Miami.
>
> But this all implies that
On 01/20/2017 09:37 PM, Graham Leggett wrote:
> On 20 Jan 2017, at 7:47 PM, David Zuelke wrote:
>
>> I'd actually like to question the whole practice of porting features back to
>> older branches. I think that's the core reason why trunk is in total
>> disarray, and why no
On 20 Jan 2017, at 4:29 PM, William A Rowe Jr wrote:
>>> Right now, there are a number of gratuitous breaking changes on trunk
>>> that change binary ABI. I'm considering a trunk fork to preserve these
>>> changes (branches/3.x-future/?) and reverting every change to trunk/
> Am 20.01.2017 um 21:40 schrieb Jim Jagielski :
>
>
>> On Jan 20, 2017, at 3:36 PM, Jim Jagielski wrote:
>>
>>
>> If I really was the dictator Bill tries to insinuate that I am,
>> I would simply branch 2.5 *right now* off of trunk.
>
> In fact, I'd
> Am 20.01.2017 um 21:37 schrieb Graham Leggett :
>
> On 20 Jan 2017, at 7:47 PM, David Zuelke wrote:
>
>> I'd actually like to question the whole practice of porting features back to
>> older branches. I think that's the core reason why trunk is in total
> On Jan 20, 2017, at 3:36 PM, Jim Jagielski wrote:
>
>
> If I really was the dictator Bill tries to insinuate that I am,
> I would simply branch 2.5 *right now* off of trunk.
In fact, I'd announce 2.5-alpha "immediately" as what's
in trunk... with a set schedule that
> On Jan 20, 2017, at 3:37 PM, Graham Leggett wrote:
>
>
> We’ve had a significant amount of progress, a trunk that is so stable that
> almost all fixes and features can be backported to v2.4 without any fear of
> incompatibility, and the “fighting” is limited to very few
On 20 Jan 2017, at 7:47 PM, David Zuelke wrote:
> I'd actually like to question the whole practice of porting features back to
> older branches. I think that's the core reason why trunk is in total
> disarray, and why no substantial releases have been made. There is just no
>
> On Jan 20, 2017, at 12:47 PM, David Zuelke wrote:
>
>
> I'd actually like to question the whole practice of porting features back to
> older branches. I think that's the core reason why trunk is in total
> disarray, and why no substantial releases have been made. There is
> On Jan 20, 2017, at 9:26 AM, William A Rowe Jr wrote:
>
>
> Just so we are all in agreement, 2.4 has been neither conservative nor
> maintenance in any conventional sense, for the past four years. Instead
> we have users relying on the stable 2.2 release which we will
On Fri, Jan 20, 2017 at 12:47 PM, David Zuelke wrote:
> I'd actually like to question the whole practice of porting features back to
> older branches. I think that's the core reason why trunk is in total
> disarray, and why no substantial releases have been made. There is just
> On 20.01.2017, at 15:34, William A Rowe Jr wrote:
>
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke wrote:
>> I don't know any framework/language/library out there that handles it that
>> strictly. Nginx, or Ruby, or PHP, or whatever...
>>
>> From
On Thu, Jan 19, 2017 at 6:05 PM, Jim Jagielski wrote:
> Bill wrote:
>
>>I think one of our disconnects with 2.4 -> 2.6 is that in any other
>>framework, there would be
>> no ABI breakage in 2.6. That breakage would be deferred to and shipped as
>> 3.0.
>
> Huh? For just one
On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke wrote:
> I don't know any framework/language/library out there that handles it that
> strictly. Nginx, or Ruby, or PHP, or whatever...
>
> From x.y.z to x.y.z+1, retain full compatibility.
>
> From x.y.z to x.y+1.0, keep external API
On Fri, Jan 20, 2017 at 4:04 AM, Graham Leggett wrote:
> On 19 Jan 2017, at 11:43 PM, William A Rowe Jr wrote:
>
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>>
On Thu, Jan 19, 2017 at 6:46 PM, Eric Covener wrote:
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr
> wrote:
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>>
On 19 Jan 2017, at 11:43 PM, William A Rowe Jr wrote:
> I think one of our disconnects with 2.4 -> 2.6 is that in any other
> framework, there would be no ABI breakage in 2.6. That breakage
> would be deferred to and shipped as 3.0.
>
> The httpd project choose to call
> Am 20.01.2017 um 01:46 schrieb Eric Covener :
>
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr
> wrote:
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>>
On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr wrote:
> I think one of our disconnects with 2.4 -> 2.6 is that in any other
> framework, there would be no ABI breakage in 2.6. That breakage
> would be deferred to and shipped as 3.0.
>
> The httpd project choose to call
I don't know any framework/language/library out there that handles it that
strictly. Nginx, or Ruby, or PHP, or whatever...
From x.y.z to x.y.z+1, retain full compatibility.
From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed,
break internal API if absolutely needed
Bill wrote:
>I think one of our disconnects with 2.4 -> 2.6 is that in any other framework,
>there would be
> no ABI breakage in 2.6. That breakage would be deferred to and shipped as
> 3.0.
Huh? For just one single, simple example, what about APR??
Are we going to now redefine the
On 01/19/2017 01:43 PM, William A Rowe Jr wrote:
Once this is complete, binary breaking ABI changes would live in
their own feature development forks. They would never be folded
into trunk until there was a group consensus to push forward to
version next.0.0 in the immediate future. trunk/ would
Am 19.01.2017 um 22:43 schrieb William A Rowe Jr:
I think one of our disconnects with 2.4 -> 2.6 is that in any other
framework, there would be no ABI breakage in 2.6. That breakage
would be deferred to and shipped as 3.0
every PHP version in the past decade (5.3, 5.4, 5.6, 7.0, 7.1, 7.2) is
I think one of our disconnects with 2.4 -> 2.6 is that in any other
framework, there would be no ABI breakage in 2.6. That breakage
would be deferred to and shipped as 3.0.
The httpd project choose to call 2.minor releases as breaking
changes. Due to poor design choices, or frequent refactorings,
26 matches
Mail list logo