Hi Jacques, the idea is that if we fix something in a release, for example 15.12.01 then it is implied that all future releases will be also fixed: 15.12.03, 04 but also 16.xx.xx etc... In fact by policy we always fix in trunk and then backport if needed.
Cheers, Jacopo On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 10/04/2016 10:35, Jacques Le Roux a écrit : > >> Hi Jacopo, inline... >> >> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >> >>> Jacques, thanks for raising this point that I think is worth of some >>> clarifications and enhancements to get the best out of the Jira reports. >>> >> [...] >> >>> "Upcoming branch" should be used to mark all the issues that are >>> implemented in the trunk and not backported in the release branches >>> >> >> So, apart maybe some very specific cases, could we in others words say it >> should not be used by bug fixes? >> About the very specific cases, I wonder when a bug fixes cannot be >> backported, notably to the last release branch. >> I see only when a refactoring makes it too much troubles. Which also show >> that the refactoring was not well done: the bug should have been fixed >> during the refactoring[1]. >> Then it's maybe better to backport the refactoring AND the bug fixes on >> the refactoring... >> > > Hi Jacopo, > > I think a simple question with an example is better: > > See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to > Tomcat 8. > It's a bug fix because there is a disputed vulnerability in Tomcat 7 > (CVE-2013-2185 tomcat-7.0.68-jasper.jar) > I set the fixed versions as, Upcoming Branch, 15.12.01 because I > committed in trunk and R15.12. > > From what you said I should only set 15.12.01. > But then how users will know (in release notes) that the next coming > branch has been fixed also? > > Thanks > > Jacques > >
