How do committers decide which features to backport to 18.12?

[Daniel Watford <da...@foomoo.co.uk>]

Hello,

I would quite like to see
https://issues.apache.org/jira/browse/OFBIZ-11330 (Using
FlexibleStringExpander in form widget field's parameter names) backported
to the release18.12 branch as, quite selfishly, it will make my life
easier! :)   I also like to think it would be useful to others too.

To try and understand how committers decide on patches to backport to
release branches I did a little searching on Confluence and found
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities

This page mentions that only bugfixes would normally be backported to
active release branches, but since 18.12 is not released yet I assume it
doesn't count as 'active'.

The same page says 'New features and Improvements should never get into a
release branch' but 'Exceptions may occur' and would need to be voted on by
committers.

Is this page correct with regards to current practice and, if so, how do
the committers decide on which features to backport to release branches?

If I want to propose a feature for backporting should I create a PR/patch?

If new features only go in trunk, do you tend to build solutions around
trunk for your clients in order to take advantage of more up-to-date
functionality?

Thanks,

Dan.

-- 
Daniel Watford

Re: How do committers decide which features to backport to 18.12?

[Jacques Le Roux <ja...@les7arts.com>]

Hi Daniel,

The rule is normally we only backport bug fixes, obviously to avoid regression

But if nobody disagree for simple new features or improvements sometimes we backport.

Most of the time a simple comment in the related Jira is enough.

If discussion is needed (big or complicate stuff) it should happen here (on dev ML).

The ASF motto is "If it did no happen on the ML, it did not happen at all" but we are not rigorists ;)

A PR is in most cases the best way.

Again for obvious reasons (stability), we don't recommend to build clients solutions on the trunk.

In other words you do it at your own risk and expenses.

HTH

Jacques

Le 24/02/2020 à 08:35, Daniel Watford a écrit :
> Hello,
>
> I would quite like to see
> https://issues.apache.org/jira/browse/OFBIZ-11330 (Using
> FlexibleStringExpander in form widget field's parameter names) backported
> to the release18.12 branch as, quite selfishly, it will make my life
> easier! :)   I also like to think it would be useful to others too.
>
> To try and understand how committers decide on patches to backport to
> release branches I did a little searching on Confluence and found
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities
>
> This page mentions that only bugfixes would normally be backported to
> active release branches, but since 18.12 is not released yet I assume it
> doesn't count as 'active'.
>
> The same page says 'New features and Improvements should never get into a
> release branch' but 'Exceptions may occur' and would need to be voted on by
> committers.
>
> Is this page correct with regards to current practice and, if so, how do
> the committers decide on which features to backport to release branches?
>
> If I want to propose a feature for backporting should I create a PR/patch?
>
> If new features only go in trunk, do you tend to build solutions around
> trunk for your clients in order to take advantage of more up-to-date
> functionality?
>
> Thanks,
>
> Dan.
>