Hi Timo, Howard and sssd-devel list,
Over time, there has been a lot of functionality, but also a bit of cruft accumulated in
SSSD. We’ve been discussing removing some old code for some time with the other RH
developers and we’d like to propose that the next .0 is the one that breaks the backwards
compatibility a bit. We’d also like to signify that the release is important by bumping
the major version number and calling the release 2.0.
We’ve been (provisionally) putting the tickets that break compatibility into the 2.0
milestone in Pagure and tagging them with “breaks compatibility” so you can find them
here:
https://pagure.io/SSSD/sssd/roadmap?status=Open&tag=breaks+compatibil...
I think most of what we propose to remove is fairly obscure and I even hope none of the
features is actually used.
Apart from those, we’d also like to switch the default upstream crypto from Mozilla NSS to
OpenSSL:
https://pagure.io/SSSD/sssd/issue/3495
There are other things we’d like to highlight with bumping the version to 2.0 like the
ability to socket-activate services or using just drop-in config files with no sssd.conf
at all, but the thing I think should be discussed first is the backwards
(in)compatibility..
Because SSSD release schedule is often related to the Fedora release schedule, we’d like
to propose that the release that breaks compatibility happens before the Beta deadline of
the next Fedora release:
https://fedoraproject.org/wiki/Releases/28/Schedule
specifically:
2018-02-20 - Branch Fedora 28 from Rawhide (Rawhide becomes future F29)
This doesn’t have to be 2.0 per se but perhaps 2.0-beta, the important thing to us is to
remove the code for F-28.
What I’m wondering is:
- Do you have any concerns with removing these features in general? Do you know if any of
your users or customes rely on these features?
- Would this release schedule fit into your distributions’ schedule?
Thank you for your help!