Do we agree you can't change the API, whether it is ABI compatible or not? Or was there a follow-up commit I missed?
On Mon, Jan 24, 2022 at 11:20 AM William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Jan 20, 2022 at 9:38 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > > > On Thu, Jan 20, 2022 at 3:56 PM William A Rowe Jr <wr...@rowe-clan.net> > > wrote: > > > > > > On Thu, Jan 20, 2022 at 8:50 AM Eric Covener <cove...@gmail.com> wrote: > > > > > > > > > Code that will compile on 1.7.1 release > > > > > still won't compile on 1.7.0, unless I misunderstand something. > > > > > > > > Is it a requirement in this direction? > > > > https://apr.apache.org/versioning.html says "later versions" > > > > > > That's why I raise the question, I don't have the authoritative answer. > > > > > > Our SVN participants who adopted and recommended strongly that > > > APR follow the semantic versioning [1] approach so they could -also- > > > adopt it probably feel more strongly about this. > > > > > > "Bug fixes not affecting the API increment the patch version, backwards > > > compatible API additions/changes increment the minor version, and > > > backwards incompatible API changes increment the major version." > > > > It was proposed in another thread to add the APU macros to 1.7.x to > > ease later migration to 2.x, I don't think that adding these apr_pool_ > > macros can have more compat issues.. > > I've been looking for follow up... seeing none, I'd point to SemVer 2.0.0 spec > bullet points 6. and 7. which clarify patch and minor bumps. > > Adding the pool macros changed the API, so therefore they cause APR 1.8.0, > adding apu->apr compatibility macros will change the API, and therefore > cause APR-util 1.8.0. Even a noop macro introduces an API. > > Are the authors willing to revert all manner of version breakage so we can > jump > forward first with the patch release tag, and then the 1.8.0 (even an > -rc1) tags?
