packaging_branching_strategy.markdown

## Int/Pak Branching Strategy

Since we're not doing the SR, we have some freedom to decide how we branch, tag, etc.

### RPM

Requirements:
* We need to be able to build any version of the RPM.
* We need to be able to serve updates to multiple streams, for example 3.0.0 to 3.0.1 and 2.3.0 to 2.3.1.

We'll either have to duplicate code explicitly in one branch or we'll hide the duplication by maintaining multiple long-running release branches.

We can also just tag when we do a release (say 2.3.0), then when we need to do a release under it (say 2.3.1) we base it off the tag, make our changes, commit, build and push.

We should be able to "build any version" by checking out the commit that introduced that version in many cases. However, I can imagine cases where the version is updated in one commit but a CBS-acceptable RPM wasn't produced for a few additional commits. This would be difficult for the maintainer to track, and very difficult to automate.

Overall, keeping multiple long-running release branches seems very complex.

Keeping a single master and explicitly maybe-duplicating logic to be able to simultaneously build all RPMs is the other option.

We'd basically need to restructure our build script to build some set of RPMs.

We would want a spec file for every release and SR.

Wouldn't be able to build frequent CR-world releases like this, would have too many spec files. Would need a new strategy for those, but even then we might keep this around for official releases.

So, maybe accepting replacing "build any version of the RPM" with "build any release or SR of the RPM"

I think this strategy is much simpler and easier to maintain. I also suspect it would be easier to integrate with our build system.

### Packer

Requirements:
* Need to be able to build any release or SR of the Vagrant base box and container
* Need to be able to do ^^that for multiple OSs

I think Packer's built well enough that this is pretty easy by just passing vars? By easy, I mean quite trivial, clearly built into the design.

This would work well with a single-branch model and awkwardly with a branch-per-release model.

### Docker

I don't think we should spend much effort trying to support building many releases and SRs via Dockerfiles. We have Packer, which is much better suited.

We have our git history to provide access to past versions.