SSSD 2.0 and breaking compatibility

[Jakub Hrozek]

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+compatibility...
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!