couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <dus...@spy.net>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 02:25:33 GMT

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




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message