Proposed version and branch policy in the SSSD

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As the subject implies, I think we need a branch policy in the SSSD to
address things like the recent security update that we released for
0.4.1. Currently there is no obvious way in the upstream tree to
retrieve a safe copy of the 0.4.1 source to compile. You would have to
be aware that the code tagged as 0.4.1 also requires cherry-picking a
specific commit from the master branch to address a security bug.

Furthermore, we don't have a consistent definition about the components
of our version string. I'd like to recommend the following policy for
these two things.

Version components:
Major version: Should reflect our current major goal. It will become 1
once we support all features necessary to replace nss_ldap, pam_ldap and
pam_kerberos entirely.
Minor version: These should represent feature-enhancement releases to
the SSSD. For example, the major features intended in SSSD 0.5.0 will be
support for the LDAP id backend and the Kerberos auth backend.
Point version: These should represent bugfixes and security patches ONLY
for the minor revision.

Branch policy:
When the master branch has reached a point where we believe it to be
ready as a new minor version (e.g. 0.5.0), we should tag that point
(sssd-0_5_0) and create a new branch from that tag (sssd-0_5).
Development should continue on the master branch. If there are fixes
needed to continue supporting 0.5.x, they should be cherry-picked into
the sssd-0_5 branch and tagged as 0.5.x+1.
In the case of bugfixes, they can be queued up and released as a single
point release when it is convenient. In the case of security issues, on
the date of the embargo lift, these should be immediately merged in and
a new point release generated.


Comments and criticisms welcome.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkp64oQACgkQeiVVYja6o6OYAQCfStMlqwb1toFD/k+lT0TSkTuF
> +44AoKIxPs+jV9XNgBWOBiufAXi8OKJ8
> =mhG3
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Thu, 2009-08-06 at 10:02 -0400, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  As the subject implies, I think we need a branch policy in the SSSD to
>  address things like the recent security update that we released for
>  0.4.1. Currently there is no obvious way in the upstream tree to
>  retrieve a safe copy of the 0.4.1 source to compile. You would have to
>  be aware that the code tagged as 0.4.1 also requires cherry-picking a
>  specific commit from the master branch to address a security bug.
>  
>  Furthermore, we don't have a consistent definition about the components
>  of our version string. I'd like to recommend the following policy for
>  these two things.
>  
>  Version components:
>  Major version: Should reflect our current major goal. It will become 1
>  once we support all features necessary to replace nss_ldap, pam_ldap and
>  pam_kerberos entirely.
>  Minor version: These should represent feature-enhancement releases to
>  the SSSD. For example, the major features intended in SSSD 0.5.0 will be
>  support for the LDAP id backend and the Kerberos auth backend.
>  Point version: These should represent bugfixes and security patches ONLY
>  for the minor revision.
>  
>  Branch policy:
>  When the master branch has reached a point where we believe it to be
>  ready as a new minor version (e.g. 0.5.0), we should tag that point
>  (sssd-0_5_0) and create a new branch from that tag (sssd-0_5).
>  Development should continue on the master branch. If there are fixes
>  needed to continue supporting 0.5.x, they should be cherry-picked into
>  the sssd-0_5 branch and tagged as 0.5.x+1.
>  In the case of bugfixes, they can be queued up and released as a single
>  point release when it is convenient. In the case of security issues, on
>  the date of the embargo lift, these should be immediately merged in and
>  a new point release generated.
>  
>  
>  Comments and criticisms welcome. 
I would just adopt the same unwritten policy we used in FreeIPA.
If we need to make a security release we branch and add patches on top
of that branch. The branch is created out of the release tag.
It is not necessary to branch at every release, only is we want to make
an upstream security release not based on master.
(Distributions can simply embed the patch in their packages if they are
not shipping master).

Once we will reach version 1, we will evaluate if we want to have a
stable vs development branch, in which case we will branch 1.0.x and
there we will do only bugfixing while keeping development in master.

Simo.