I like the approach Todd outlines, but have been doing it as Stack describes.
+1 on moving to Todd/Hadoop approach. In addition, for JIRA, we should probably put the fix version as the lowest common denominator rather than everywhere it is applied. (if fixed in 0.90 branch, it's not really a bug fix when we release 0.92 since it was already fixed on the previous major release).
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stack
> Sent: Monday, February 07, 2011 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CHANGES.txt in trunk vs branch?
> Thanks Todd. Sounds good.
> I 'think' that in the past we would do different to Hadoop in that we'd just
> bundle the fix issue under the explicit fix version on branch but under the
> current trunk version when we added the fix into trunk; i.e. using your
> version example below, we'd put fix under
> 0.90.1 out on branch but under 0.92 in TRUNK.
> On Mon, Feb 7, 2011 at 12:35 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> > Hey all,
> > I wanted to clarify/ask what our policy is for updating CHANGES.txt on
> > trunk when something is committed to both trunk and branch.
> > In the Hadoop project we add the patch to the branch section on both
> > trunk and branch. That is, if we're working on 0.92 and put a patch in
> > 0.90.1, it will go in the "0.90.1" section on both svn branches. This
> > makes it easier to use svn merge or git cherry-pick to move commits
> > between branches, and also I think makes more sense to a user. For
> > example, if a user upgrades from 0.90.2 to 0.92 some day, they would
> > expect to have all the changes from 0.90.3, 0.90.4, etc - but not see changes
> from 0.90.1 again.
> > Does this jive with what other people think? If so I'll go through and
> > move entries from the 0.92 section of CHANGES.txt back into 0.90.1
> > where they've been committed to both branches.
> > -Todd
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera