On Thu, Sep 26, 2024 at 10:16 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den tors 26 sep. 2024 kl 15:31 skrev Johan Corveleyn <jcor...@gmail.com>: > (snip) >> >> +1, definitely. Since BDB support in Subversion is already deprecated since >> 1.8 [1], i.e. already more than 10 years! > > > Thanks, I've done that in r1920956. > > (...) >> >> Now that you mention it, [1] says: >> [[[ >> At some point, support for the BDB back-end will be completely removed. We >> will announce such removal well in advance of its happening. >> ]]] >> >> Maybe it's long overdue that we actually do that? It's been deprecated for a >> decade ... >> Though as we promised here, we should "announce such removal well in >> advance", so not sure how we should go about it. > > > We also have the promise that all minor versions (1.1, 1.2, 1.8, 1.14) should > be API compatible. Does removing BDB break that promise? On the other hand, > shipping features long ago deprecated probably mean they don't get much > testing and much care from dev@. > > If the answer to the previous question is "yes, we can't do that": What would > be needed to release 2.0? Maybe we could just sweep through all deprecated > functions and remove them. We could even keep the "version number" in the > prototype, to avoid breaking things downstream for the users who already use > the latest version. Maybe we should formally discuss and agree on a future > for the build system - if we would decided to deprecate autoconf for CMake, > that might be another thing in 2.0. Or even just start planning for 3.0 some > time further ahead.
I had thought of such a sweep, but am concerned that some projects that rely on old APIs (that are still supported via calling the new APIs internally) might not have the energy, desire, etc., to update their code. OTOH I don't know how big of a concern that actually is. We could try to reach out to various projects and ask? Regarding BDB, I would suggest to announce that BDB has been deprecated for 10 years and X releases and it will be REMOVED in the next minor release (1.15) unless someone steps forward to maintain it adequately. The announcement could include text to the effect that the BDB backend is "obsolete, no longer maintained, and no longer tested; will be removed in 1.15; please migrate all BDB repositories to FSFS as soon as possible" (or some words to that effect). It could be announced in the following places: * announce@ * website News section (always pinned, until 1.15 release) * 1.14.4 release announcement * 1.14 release notes If we don't get around to actually removing the BDB backend code before 1.15, it could still exist in the tarballs but with additional notes that it is "obsolete, not maintained, and no longer tested" in: * 1.15 release notes * configure warning if building with bdb in 1.15 10 years and lots of notice about deprecation sound like they "should be enough for everyone" but tell that to everyone who still uses Python 2. :-) Cheers, Nathan
