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. At one point, a new major release was to indicate big changes, but even the Linux kernel these days change major version without much more reason than Linus thinks it is about time (at least that's the impression I've got). Kind regards, Daniel >
