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.
