On Mon, Feb 19, 2018 at 12:50 PM, Joe Orton <jor...@redhat.com> wrote:
> On Sat, Feb 17, 2018 at 02:06:20PM -0000, minf...@apache.org wrote:
>> Author: minfrin
>> Date: Sat Feb 17 14:06:20 2018
>> New Revision: 1824592
>>
>> URL: http://svn.apache.org/viewvc?rev=1824592&view=rev
>> Log:
>> Update proposal with fix for rpluem/jorton.
>
> Extending dav_resource still breaks binary backards compat with all(?)
> consumers of this API, or am I missing something here?
>
> Look at what mod_dav_svn does with the struct for an example:
> https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l80
(We can continue this from top-thread, but was this question
posed to or already considered by dev@svn?)
> If breaking backwards compat for module API is fine for 2.4 (and I'm
> still generally on the fence about this), I think it should at least be
> a "hard" break, e.g. by s/dav_register_provider/dav_register_provider2/.
> That way incompatible module combinations break at LoadModule time
> rather than with segfaults.
This is our Announcement policy;
This release builds on and extends the Apache 2.2 API. Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.4, and require minimal or no source code changes.
http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
When upgrading or installing this version of Apache, please bear in mind
that if you intend to use Apache with one of the threaded MPMs (other
than the Prefork MPM), you must ensure that any modules you will be
using (and the libraries they depend on) are thread-safe.
Implication from the above, Modules written for Apache 2.4 will not need
to be recompiled in order to run with Apache 2.4.
Reading that linked document in reverse;
DEVELOPMENT RELEASES, 2.{odd}.{revision}
-----------------------------------------
All odd numbered releases designate the 'next' possible stable release,
therefore the current development version will always be one greater than
the current stable release. Work proceeds on development releases, permitting
the modification of the MMN at any time in order to correct deficiencies
or shortcomings in the API. This means that modules from one development
release to another may not be binary compatible, or may not successfully
compile without modification to accomodate the API changes.
In other words, modules from one STABLE release to another ARE binary
compatible and do NOT need to be recompiled.
This is clearly not true of several recent changes, even though they
impact relatively few third party modules.
I suggest that since the majority here accepted binary breakage as OK,
that the project at MINIMUM now documents every known third party
module that must be 1) modified in source or 2) recompiled for binary
breakage, and we place that full appendix in every Announcement, and
on the main httpd website announcement and download page (followed by
some "... and similar modules" caviet, since people may have forked
the logic from these third party examples.
Or I suggest we back out breaking changes and go back to what this
project previously agreed upon and promised for the lifespan of 2.4.x.
I don't believe we ever had unanimous consensus, the change to
ABI-strict versioning was a majority vote at the end of the day?
Changing that policy mid-version seems utterly stupid to me, but I'm
tired of people taking personal offense at -1's, so repeating what
I've said, I'm neither supporting nor opposing any 2.4.x changes.
Simply reminding the list of the basis for our policies.
