On Wed, Apr 11, 2012 at 6:24 AM, Marcin Cieslak <saper(a)saper.info> wrote:
Hello,
I have a problem similar to the one of RELEASE-NOTES.
After great pains (broken merges, unknown dependencies, etc.)
I have pushed f74ed02ef744138a8d2a87322f81023ddc143a5f where
I have marked some methods "@since 1.19" since I really hope
to have this backported to 1.19 and maybe even 1.18.
How should we handle the @since stuff? What if it never
gets merged to the release branch? If not, which one?
I personally don't think documentation such as @since
is worth backporting. Others may disagree, but I really
don't see it as worth the effort and potential conflicts.
Should REL1_18 say @since 1.18.3 and REL1_19 @since
1.19
or should all consitent mention the lowest (although
1.18.4 may be younger than, say 1.19)?
We really really shouldn't be adding new public methods or
changing APIs in point releases (1.18.1 vs. 1.18.2).
Or, once something "@since 1.20" gets merged
in to REL1_19,
I should modify @since to 1.19 in master and update
master's RELEASE-NOTES-1.19 as well?
We've never listed documentation fixes like this in release
notes, I don't see any reason to start now.
The answer I got on IRC is that it is usually up to
the
developer to plan for which release it should go to
in advance; but I can understand that my changes
won't be allowed into, say, REL1_18 for this reason or another
(they are not security fixes, for example).
We should never backport new features, this has been a
policy for a long long time. The only things that should be
backported are bug fixes (and even then, we generally only
backport if it's a breaking issue or a regression). But like I
said on IRC yesterday--fixes should always go into master
first and then we discuss backporting. Putting changes into
the gerrit for multiple branches at the same time risks them
getting merged at different times or otherwise getting out of
sync.
This is also a good use of gerrit's topic feature, it helps you
to group things that are related but on different branches (and
free-form tagging will improve this further).
-Chad