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 min
Agreed all the way around...
PS: I *think* we also did this before, when we needed
to bump up some *scoreboard* field sizes (to support
IPv6) and we still did it w/ a minor bump, iirc.
On Sep 4, 2014, at 2:02 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>
>> -Ursprüngliche Nachricht-
>
I think, in this case, a minor could be justified.
On Sep 4, 2014, at 1:57 PM, Plüm, Rüdiger, Vodafone Group
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-
>>
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Donnerstag, 4. September 2014 19:58
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS
>
>
> On Sep 4, 2014, at 6:13 AM, Ruediger Pluem wrote:
>
> > Can we really backport th
On Sep 4, 2014, at 6:13 AM, Ruediger Pluem wrote:
> Can we really backport this?
>
> We are increasing the size of proxy_worker_shared and changing offsets inside
> the struct.
>
True, but if we bump the mmn, that should cover it.
I know of no-one other than httpd that uses that struct anyw
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:j...@jagunet.com]
> Gesendet: Donnerstag, 4. September 2014 19:55
> An: dev@httpd.apache.org
> Betreff: Re: s
I think we can, as long as we bump the MMN...
On Sep 4, 2014, at 7:22 AM, Rainer Jung 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
As long as we bump mmn, we should be OK.
On Sep 4, 2014, at 6:13 AM, Ruediger Pluem wrote:
> Can we really backport this?
>
> We are increasing the size of proxy_worker_shared and changing offsets inside
> the struct.
>
> Regards
>
> Rüdiger
>
> rj...@apache.org wrote:
>> Author: rjung
>> D
On 9/4/2014 8:49 AM, William A. Rowe Jr. wrote:
I overlooked 2 other viable options
[ ] Roll -win32-src-r2.zip with apr-util 1.5.2 (pre-breakage) and
corresponding binaries
[ ] Roll -win32-src-r2.zip with apr-util 1.5.4 (upon release) and
corresponding binaries
Assumes a much quicker path to
I picked 2010 because it's what I have :)
But that's sort of the point of my question. Why pick something so old
as VC6 and not something newer, and hopefully better.
FYI, I'm not complaining or nit-picking. I'm a complete newbie hack at
Windows development and trying to understand the train of
Good point. I'd forgotten about compatibility with third party modules.
That said, by "arbitrarily" selecting VC6 aren't you also stuck with the same
problem?
Thanks,
Andy
On Thu, 2014-09-04 at 08:33 -0700, wr...@rowe-clan.net wrote:
You can do this. However, that doesn't solve the problem fo
According to:
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
And
the redist.txt file in the Visual Studio Redist directory:
For your convenience, we have provided the following folders for use when
redistributing VC++ runtime files. Subject to the license terms for the
software, you may
I overlooked 2 other viable options
[ ] Roll -win32-src-r2.zip with apr-util 1.5.2 (pre-breakage) and
corresponding binaries
[ ] Roll -win32-src-r2.zip with apr-util 1.5.4 (upon release) and
corresponding binaries
wr...@rowe-clan.net wrote:
>Finally returned to VC6, having replaced my older
- Original Message - Subject: Re: C99 bump prior to apr 2.0?
From: "Wang, Andy"
Date: 9/4/14 9:48 am
To: "dev@httpd.apache.org"
Is there a reason to not bundle the msvcrtxxx.dll that's microsoft includes in
the redist area?
So that's what we've taken to doing with our apache. S
You can do this. However, that doesn't solve the problem for users of one
distribution of httpd (from any origin, not just the ASF) linked to a particular
msvcr###, interoperating with a module built by another third party for a
different msvcr### (or trying to build your own add-in with a compile
You can't, AFAIK, due to licensing. You need to include the *installer*
that comes in VC's redist area and can run that installer from yours to
install their runtime...
Or you can statically link to the runtime, but I'm not sure we want to
do that.
On 04/09/2014 17:48, Wang, Andy wrote:
> Is the
Is there a reason to not bundle the msvcrtxxx.dll that's microsoft includes in
the redist area?
So that's what we've taken to doing with our apache. Simply including the
version that microsoft bundles with 2010 in the web server bin directory.
Thanks,
Andy
On Wed, 2014-09-03 at 17:52 -0500, Wi
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
Can we really backport this?
We are increasing the size of proxy_worker_shared and changing offsets inside
the struct.
Regards
Rüdiger
rj...@apache.org wrote:
> Author: rjung
> Date: Thu Sep 4 09:21:16 2014
> New Revision: 1622429
>
> URL: http://svn.apache.org/r1622429
> Log:
> Propose.
>
19 matches
Mail list logo