On 2024/09/26 23:14, Daniel Sahlberg 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@.
The promise is only for public APIs, that is the APIs published in the
include files which would be installed to user's environment. So, the
symbol SVN_FS_TYPE_BDB should not be removed, e.g. However, function
APIs in svn_fs.h are generic interface to access for each backend fs
subsystem (and interfaces for implement new backend fs). Even some of
fs backends are not provided. those function interfeces still work
as expected. So I don't think removing bdb backend itself breaks the
promise.
Also, I know at least one function was removed from public APIs,
the API was published by accident.[1][2]
[1]
https://subversion.apache.org/docs/api/1.10/svn__dirent__uri_8h.html#a5853024ba08f8671c6fec0146b10d721
[2] https://svn.apache.org/viewvc?view=revision&revision=1850611
> 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).
Do not compare with the project actively developed, always ton of new
features are beeing added :)
Cheers,
--
Yasuhito FUTATSUKI <futat...@yf.bsdclub.org>
