I would like to suggest again that the R15.x branch be labelled and
advertised as a major rewrite that will not be backward compatible.
Let's do all of our major changes in one revision, and as Pierre
suggested, include in that revision instructions on how to migrate from
pre-R15 to post-R15.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/25/2015 10:24 AM, Jacopo Cappellato wrote:
On Apr 25, 2015, at 10:39 AM, Pierre Smits <[email protected]> wrote:
I can imagine that some will vote a -1 regarding this reorganisation of the
structure, as this will break backward compatibility and puts the pressure
on all those users who have created extensions and replacements
Same here, and I really hope that people will not oppose to new ideas because
of the concerns on backward incompatibilities or impact on existing investments.
The OFBiz codebase needs to evolve into the future and this cannot be done if
every new ideas gets a pushback because of impacts on other systems or user
base: I see this trend happening lately and I think it is not wise.
I am not saying that backward compatibility, stability and migration plans are
not important factors: but I think they should not influence new ideas; only
after a new ideas is considered valid for OFBiz, we should then focus on how to
implement a roadmap to alleviate the pains of external codebases or users.
We could create a stable release branch right before we start working to
incompatible changes etc... but we should discuss what to do only after we have
decided about the future.
Jacopo
