What is the effect of this strategy on the implied warranty?
What is "guaranteed to be tested?
Where will the test results for the release be available?
What is the responsibility of someone who changes the release branch
after it is "released" in terms of testing, support and documentation?
Is this going to make fixing bugs found in a release to onerous?
What is the effect on documentation and the web site in terms of
describing the release?
Ron
On 28/11/2014 5:24 AM, Jacques Le Roux wrote:
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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
