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
