Yeah... I could have *swore* that we allowed this before with
the scoreboard, but can't for the life of me find it...
Must be dusty neurons.

Agreed that it breaks ABI to change the struct. :/

On Sep 4, 2014, at 3:44 PM, William A. Rowe Jr. <[email protected]> wrote:

> No... only if the patch is restructured to preserve all existing structure 
> members at their current offsets.  New struct members at the end of an 
> existing structure is the definition of a minor mmn bump.  If third party 
> module authors allocate ap structs, it is their job to track against mmn 
> minor revs.
> 
> 
> Jim Jagielski <[email protected]> wrote:
> 
> I think, in this case, a minor could be justified.
> 
> On Sep 4, 2014, at 1:57 PM, Plüm, Rüdiger, Vodafone Group 
> <[email protected]> wrote:
> 
> > But IMHO that would be a major bump and not a minor one. And we cannot do 
> > major ones in stable branches.
> > 
> > Regards
> > 
> > Rüdiger
> > 
> >> -----Ursprüngliche Nachricht-----
> >> Von: Jim Jagielski [mailto:[email protected]]
> >> Gesendet: Donnerstag, 4. September 2014 19:55
> >> An: [email protected]
> >> Betreff: Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS
> >> 
> >> I think we can, as long as we bump the MMN...
> >> 
> >> On Sep 4, 2014, at 7:22 AM, Rainer Jung <[email protected]> wrote:
> >> 
> >>> Am 04.09.2014 um 12:13 schrieb Ruediger Pluem:
> >>>> Can we really backport this?
> >>>> 
> >>>> We are increasing the size of proxy_worker_shared and changing
> >> offsets inside the struct.
> >>> 
> >>> Bummer, I guess you are right. mod_proxy.h seems to be part of the
> >> public API so we can't backport like this. Will revoke the proposal.
> >>> 
> >>> We could think about adding new larger name fields to the end of the
> >> struct and keep a truncated copy in the original struct mebers. But that
> >> means 3rd-party modules using the old original fields would only see
> >> part of the names.
> >>> 
> >>> Rainer
> >>> 
> > 
> 

Reply via email to