Skip to content

Instantly share code, notes, and snippets.

@M4rtinK

M4rtinK/anaconda_branching.rst

Last active June 7, 2016 13:06
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save M4rtinK/56ed2a2bbd2f55504fc266192fbba3b1 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save M4rtinK/56ed2a2bbd2f55504fc266192fbba3b1 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
anaconda_branching.rst

Possible Anaconda Git branching model

The idea is to have these four branches:

  • master
  • unstable
  • <next fedora number>-release
  • <next fedora number>-devel

The idea is that the master branch never waits for any release related stuff, which is pretty much how it is now. The main difference is that the master branch also no longer contains rawhide release commits, but the spec file is still there to track dependencies.

The unstable branch is used for making periodic Anaconda releases for Rawhide (or possibly anyone else wanting to taste the cutting edge).

Before each release:

  • master is merged to the unstable branch
  • a release commit is made (bumps version in spec file) & tagged

Rinse and repeat for another Rawhide build.

Now about the <next Fedora number branches> (could be also called next stable release if we wanted to decouple our versioning from Fedora in the future):

  • the idea is that stuff we want to go to the next fedora goes to <next Fedora number>-devel, which is periodically merged back to master
  • this way we can easily see what was developed in which Fedora timeframe and possibly due to given Fedora testing phase feedback (bugfixes, etc.)
  • stuff we don't want to go to the next Fedora (too cutting edge, etc.) goes only to the master branch
  • commits specific to given Fedora release (temporary fixes, etc.) go only to the <next Fedora number>-release branch
  • the <next Fedora number>-release branch also contains release commits

Example for the F25 cycle:

  • master
  • unstable
  • f25-devel
  • f25-release

This would continue until F25 is released, after that we:

  • drop the f25-devel branch
  • keep f25-release as an inactive record of the f25 cycle
  • branch f26-devel and f26-release from the master branch

This will result in the following branches for the f26 cycle:

  • master
  • unstable
  • f26-devel
  • f26-release

As for the current RHEL branches - they are just too divergent to reasonably integrate to this scheme. I guess we could at least start merging pull requests for the RHEL branches to give the commits in the PRs some context, but two pull requests will still be needed:

  • one for the rhel<number>-branch
  • one for the master or <fedora number>-devel branch (if the change is not RHEL only)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment