[SSSD] The future of the 1.5 and 1.8 LTM branches

Jakub Hrozek jhrozek at redhat.com
Mon Feb 4 14:53:54 UTC 2013


Hi,

As you may know, some SSSD releases are designated as Long Term
Maintenance releases and maintained for much longer time than regular
releases, making them suitable for use in distributions such as RHEL,
SLES or Ubuntu LTM. The current maintenance policy was announced here:
https://lists.fedorahosted.org/pipermail/sssd-devel/2011-January/005474.html

However, when RHEL6.4 is released, it will also include a rebase of SSSD
to 1.9. That will get us into a strange situation, because on one hand,
most upstream developers are most familiar with RHEL and Fedora, but the
only other supported release still using the LTM 1.8 branch will be
Fedora 17.

As the tentative plan for RHEL6 is to stay on the 1.9 branch, I think it
makes sense to proclaim 1.9.4 the next LTM release. In particular, I'd
like to do the following:

1) Release 1.5.17 with the fixes that accumulated since 1.5.16.
These are: git log --oneline sssd-1_5_16..sssd-1-5
1.5.17 would be the last 1.5 release and the 1.5 branch would become
EOL upstream.

2) 1.9.4 would be declared the next LTM release. The 1.9 branch would
still receive bugfixes, but very few (if any) new features. New feature
development would happen on the 1.10 and later branches. We are tracking
only a couple of known bugs in the 1.9 series and no known regressions
at the moment, so I think 1.9.4 is ready quality wise.

3) The 1.8 branch will only receive the most important and security
patches from now on. It wouldn't go completely unmaintained, of course,
as I suspect many users and distributions run 1.8.x

4) At some point, another future release would be named the next LTM and
1.8 will go completely EOL about a year from that point. It is not
decided yet which release will be the next LTM. Probably not 1.10,
but rather 1.11 or even later, depending on what our long term plans
(including RHEL7) will look like.

Does the above sound reasonable?



More information about the sssd-devel mailing list