Adrian, Pierre, this is exactly what I meant.
Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Migration plans help to ensure that external issues are addressed. It also > helps to pick future release branch that will have these major changes, say > r15 or 16 and plan/work towards having everything in place for that. > > I suggest we start working on getting the JIRA side first, before the > creating the release branch so that we can get all issues identified and we > don't get confronted with things overlooked. > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato < > jacopo.cappell...@hotwaxsystems.com> wrote: > >> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pierre.sm...@gmail.com> 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
