While working with Jinghai on https://issues.apache.org/jira/browse/OFBIZ-6659
I got an idea.
We tried to remove all special purpose components but ecommerce in R13.07. We can't say it was a success, because some users complained they could not
find the component they were looking for (POS or Project Manager for instance), etc.
Now on the other hand we could still discuss the idea of removing those components from releases when still having them in the releases branches. How
to? Easy: just remove them from the branch before releasing, release without them and them revert the removing. Hop, they are here again in the
released branch and we can continue to maintain them. With a page in the wiki we explain to users how to grab the components when they need them, et
voilà :)
Now I'm not sure we still want to remove component from specialpurpose, but there were some good arguments about, more in the last thread I found
about this subject: http://markmail.org/message/rndzn6i6z2kp2zn3
Jacques
Le 28/11/2014 11:24, Jacques Le Roux a écrit :
Afterthought: we agreed about having the same setting in both the releases branches and the trunk. So if we disable a component in the releases
branches it will be also in the trunk.
Then, even we enable tests, we will not be aware of UI related issues and globally all those which are no covered by tests. Apart if an users enable
the component and report issues.
This might be a compromise, but we need our users to be aware of. So they will
need to be warned in the download page IMO.
Also if you remember this thread started with my idea of creating a wiki page to explain to our users the alternative strategy of using release
branches rather than released packages.
I'd like to have a direct link to this wiki page from the download page. This link name
could be simply "alternative strategy". What do you think?
I will stop this thread here and will create a new thread to discuss the
modality of putting back the specialpurpose components in the R13.07 branch.
Jacques
Le 27/11/2014 23:38, Jacques Le Roux a écrit :
That sounds like a good enough solution to me
Jacques
Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
This is a good point. We could find a way to programmatically enable/disable
the components just for the test run:
./ant -Denable-all=true clean-all load-demo run-tests
but this is just an idea; we could figure out the best way to go.
Jacopo
On Nov 27, 2014, at 7:14 PM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
Be aware that disabling a component does two things:
1. Speeds up unit tests because the disabled component is excluded from them.
2. Increases the chance of regressions because the disabled component is not
being tested.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
Yes, so we need to define which are those components. So 3 points, which should be discussed separately it seems, not sure of the order yet but
probably this one
1) Components to move to Attic. They will be freezed but still available in
this state in Attic (in other words slowly dying)
2) Components to disable. They will be maintained, but OOTB will not interfere
with other components (applications or other specialpurpose)
3) Components to keep enabled. They must be maintained and have no interactions
with other components
Components enabled and disabled must be maintained in the same way: it is not
that a group is more important than the other.
Also, disabling a component doesn't mean that it will not go in a release: we could have disabled components in releases and enabled components
excluded from a release or vice versa.
For the point 2 we need to clarify if it could applies to trunk also. I'd now tend to avoid differences between trunk and branch releases, at
the functionality or other levels.
I agree that the same settings should be maintained in the trunk and in the
release branches.
Jacopo