On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:
> <<the problem is not everybody is aware of bug fixes backported or not. The > official download page http://ofbiz.apache.org/download.html, says that we > stabilize releases with bug fixes. It's not quite clear if we are backporting > all or only some bug fixes.>> > A more formal rule would be: * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release > <<I think we should make that clear and expose a way to users for them to more > "easily" maintain the releases they use.>> +1 see below > > As suggested Ron we could also define our own or refer to > http://en.wikipedia.org/wiki/End-of-life_%28product%29 and Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have: • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series) But when we specify an end of life, we should also make clear a few things: * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed) * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life > > Now we need to think "technical" and automatize as possible with Jira In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the information will be more accurate with new releases). The idea is to run a query on Jira with the following constraints: project = OFBiz type = Bug status = not resolved version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. "Release 12.04.05") The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and outstanding. For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes. In the download page, we could add two links (to Jira) next to each available release: 1) known bugs (links to the above report) 2) release notes (link to the release notes available now) One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to affected version). > What I have read so far from Jacopo seems a good start to me Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when I started the version refactoring in Jira, and this conversation is helping to refine some points. Jacopo
