Re: Proposal: redefining the components' directory layout for source files

[Michael Brohl]

+1








Michael
ecomify GmbH
www.ecomify.de

Am 25.04.15 um 12:39 schrieb Jacopo Cappellato:

for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their business on the OFBiz foundation without denying serious changes just because of this fact. Maybe it is possible to provide some "migration tools" (scripts etc.) to help automate the migration and make it less painless for the users. At least a good documentation should be provided which should be started during development to get every change and best practice documented. Things often get lost when documenting later. It could be a must have for a patch for fundamental changes: no documentation, no commit.

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

smime.p7s
Description: S/MIME Cryptographic Signature