On Thu, Sep 26, 2024 at 5:34 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > 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?
I have advocated for thinking about a 2.0 in the past (mainly for creating more buzz / momentum / fresh start). But I have since changed my mind, and I don't think a 2.0 is realistic at this time. I imagine that for 99% of our user base the 1.x compat guarantees, and gradually evolving the software, are vastly more important than us creating a 2.0 to clean up some things (with little added value for users). Unless there is some new killer feature on the horizon that can only be done by breaking compatibility. It doesn't hurt to brainstorm / dream / discuss about 2.0 of course, but I would keep in mind that we might never actually get around to it. > 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@ And users@ and dev@ please. > * 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 +1 -- Johan
