389-ds-base Branching Strategy

[Simon Pichugin]

Hi team,
I want to clarify and document our branching and release strategy
to set the correct expectations for different distributions and future
389-ds-base maintainers.

Recently, I assumed that we have this branching strategy:

- The development happens in the *main.* We cherry-pick the needed fixes to
other branches as required.
- When we release a new *X.Y *version (bump version, create tag, create
release), we create a separate branch *389-ds-base-X.Y.*
- The main at this point becomes future *389-ds-base-X.Y+1* (without
bumping the version there, for now), and we continue the development there
while cherry-picking to other branches + 389-ds-base-X.Y.

It ignited a discussion... So please, if you disagree with the above,
describe the release flow you think we have/should have.
We must make it very transparent for other distributions besides
RHEL/Fedora.

Also, an important question will be:

- Do SUSE/Debian/Archlinux/etc. need the *389-ds-base-X.Y *branch created
right away after the *X.Y* official GitHub release? Or can it be postponed?
Please, maintainers, let us know.

Regards,
Simon

[William Brown]

> The development happens in the main. We cherry-pick the needed fixes to other branches as required.
> When we release a new X.Y version (bump version, create tag, create release), we create a separate branch 389-ds-base-X.Y.
> The main at this point becomes future 389-ds-base-X.Y+1 (without bumping the version there, for now), and we continue the development there while cherry-picking to other branches + 389-ds-base-X.Y.
>
> It ignited a discussion... So please, if you disagree with the above, describe the release flow you think we have/should have.
> We must make it very transparent for other distributions besides RHEL/Fedora.

I'm happy with this release process - it has worked for a long time for RH/Fedora and for us at SUSE, it allows us to have a clear and easy path to patches/backports. Most importantly, it saves us from a lot of messy and annoying hand patching in RPM's, since we can just take a branch and it's patches and work from there.
> Also, an important question will be:
> Do SUSE/Debian/Archlinux/etc. need the 389-ds-base-X.Y branch created right away after the X.Y official GitHub release? Or can it be postponed? Please, maintainers, let us know.

The way that SUSE generates it's RPM's is from git branches, and the git tag information is used for automatic version detection.

So in this case, I think when we do release version X.Y, we should branch immediately. This prevents divergence between the released tar and the maintenance branch. If you branch later, then you end up with changes from main as well which may or may not have been otherwise backported.

--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia