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?
