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.
>
Locked
