On Oct 21, 2011, at 5:42 PM, Noah Slater wrote:
> I don't follow this comment at all. 1.2 does not necessarily have everything
> 1.1 has in it. They may even diverge when we get down to the bugfix version.
> Releases are tagged from release branches which are split from trunk.
> Sometimes we apply fixes to the release branches that we do not
> "forward-port" to trunk or newer release branches. It's all there in the
> version control system. Can you clarify?
This makes sense if 1.1.1 was released after 1.2, but why would you not
want to include the 1.1 changes in 1.2? As much as I dislike using perforce
and its like, I find Laura Wingerd's Tofu Scale to be a good generally working
model.
For example, let's say 1.1 is stable, released version of software and
1.2 is a stabilizing, about to be released piece of software. A bug fix that
is important enough to require a fix in the previously released version should
also be required for 1.2. Ideally, you make the fix in 1.2 (the firmest of
branches), and then merge it up.
This is true even if the broken functionality no longer exists, because
it very clearly marks that the bug doesn't exist and how it came to not exist
(git makes it easy to do what is effectively a NOOP merge).
The end result is you can easily ask what's missing in either direction
between any two points and nothing gets lost. Show branch, github branch view,
etc... will happily show you when a maintenance branch has crept ahead of a
development branch. Otherwise, it's a lot of work to ensure things don't get
dropped. I generally prefer to leverage the tools that can do this reliably
for me.
--
dustin sallings
