On 07/04/2014 05:26 PM, Martin Kosek wrote:
When 4.0 releases, there will be several development trains that we will
need to manage in our git:

1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to
ipa-4-0 branch

ipa-4-0 branched

2) FreeIPA 4.1 "small" development - 4.1 will be just a short release
for the summer focused on Views, full support of DNSSEC, OTP local high
watermark, Backup and Restore and other small features (and possibly
also CA management tool).

ipa-4-1 branched

3) FreeIPA 4.2 big development - this is a longer, more in the future
(read Fedora 22 time frame) development with major features going in -
Vault, User provisioning, publishing CA certs to clients and many others
stuff still being scoped. It will include for example big updates to
installers which should not go to more stable 4.1/4.0.x releases.

this will be master

How to handle that in git repo? Given that we do not do merge commits, I
think the easiest way would be to:

- When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will
leave us with master, ipa-4-1, ipa-4-0 active branches
- 4.2 team will commit their work to master only
- 4.1 team will commit their work to master, ipa-4-1
- 4.0.x bugfixing team will commit their work to master, ipa-4-1 and

This may sound complicated, but with Petr's ipatool pushing to multiple
branches should be easy. Our CI should guard at least ipa-4-0 and
ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to
report failures early.

I've update the tool to take new milestones into account.
If you use the tool, please pull the changes.

If there is a better idea, please propose it. But this plan seemed to me
as the most straightforward.


Freeipa-devel mailing list

Reply via email to