On Wed, Apr 11, 2012 at 6:24 AM, Marcin Cieslak saper@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