Re: [SSSD] Proposed version and branch policy in the SSSD
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.