Le 24/03/2015 16:20, Ron Wheeler a écrit :
Sub-projects?
If anyone is still reading...
The project seems to have reached a size where managing it is getting to be too
contentious.
There was a suggestion about splitting out the framework and releasing it as a
separate deliverable.
This idea seems to have some merit.
- it would force clarity about dependencies
- it would allow the framework to be documented and "marketed" as a separate
entity for those who do not want all of the apps.
- it would allow framework bugs and enhancements (caching fix?) to be released
more often.
- it would probably add some stability to the framework by forcing applications to provide their own seed data and to be explicit about what
versions of the framework are required.
- it would allow segregation of commmitters so that people with no interest in
applications could work on the framework and vice versa.
- it would make the web site and wiki a damn sight easier to understand and
maintain.
This discussion seems to be about finding a way to split the application base into manageable units that can be released, when and if there is a
need, without holding up the progress towards a release of the core (whatever that turns out to be).
At some point the OFBiz community is going to have to bite the bullet on this and I think that this might be the time to analyze whether the current
effort in managing the floating definition of "core functionality" is more trouble than addressing it properly and breaking the project into
separately released sub-projects.
Is there a consensus of what constitutes a set of applications that absolutely must be released as a unit in order for cross applications
dependencies to work?
Can this be reduced?
I can not see any reason why it would not be acceptable to have an application that warrants that its version 15.01.1 requires framework > 12.04.0
and core 12.04.5 while version 15.03.01 requires the latest framework 13.07.xx and application core 13.07.xx.
I understand that there is some cleaning up of entities and seed data that needs to be done but it does not seem to be a problem beyond the
capabilities of the team.
Right, I think we got your idea Ron, we try to focus on the issues at hand.
Then we will be able to consider your proposition :)
Jacques
Ron
On 24/03/2015 10:26 AM, Jacopo Cappellato wrote:
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
* there are components that have issues (that can include license concerns
and/or vulnerabilities): better to leave them out from release branches
They should even not be in trunk then
I agree; but if they are in published releases this is even worse because the
PMC have to sign them. trunk is not officially published.
We discussed about these concepts several times.
Jacopo
