ant elder wrote:
On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <[email protected]> wrote:
Florian MOGA wrote:
We have identified the need of having the following types of environments:
- a place where to keep new modules or samples (contrib/)
- a place where to move the new code in order to get built regularly in
order to be able to monitor it's state and ensure doesn't get broken by
latest trunk/ changes (unreleased/)
- a place where to keep released modules and their latest
fixes/improvements (trunk/)
- a place where to copy code from the main development area in order to
experiment things which might break the build (sandbox/<personal folder>)
As a conclusion, code can be moved on the following paths contrib/ ->
unreleased/ -> trunk/ and sandbox/ <-> trunk/.
Currently, the unreleased/ folder is under trunk/ and there have been
discussions about taking it out of trunk/ at the same level with /contrib
and trunk/. The advantages would be that it would make trunk smaller and
easier to build without the new modules and their dependencies. The
disadvantages would be loosing the ability to check out trunk/ and
unreleased/ in one piece and the convenience this brings inside the
development environment. Either way Hudson will be set to build the
unreleased folder/ but not fail the trunk/ build and snapshot deployment if
unreleased/ fails.
There are other advantages of having the unreleased code in trunk and
in the default top-level trunk build.
1. Having it in trunk makes it clear that it's part of trunk and that
people making changes to trunk need to take account of any impact
that their changes have on this code.
2. Having it in the default build (not just the Hudson build) makes it
immediately obvious if something is broken and requires people to
take positive action to correct or work around the problem.
I'm -1 on having this in the default build. That wont fit well with
the way i develop in Tuscany or how i have my IDE setup, nor will it
allow the nightly build to work regardless (as commented in [1]) nor
does it match what was suggested earlier at [2]. If there's code that
everyone should be building and making sure doesn't get broken then
put it in trunk proper, if at release time you don't want that
something released for some reason then just delete it from the
release branch.
...ant
[1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
[2] http://apache.markmail.org/message/uvusqmubd4oudang
In 1.x these unreleased things are already in trunk. Some of them
are in the default build and some aren't. So I don't understand how
moving the modules currently in the default build from trunk/xxx to
trunk/unreleased/xxx and keeping them in the default build would
affect the way people develop in Tuscany or have their IDE set up.
I wasn't proposing that anything should go into the default build
that isn't there currently.
Excluding these things from the release isn't as simple as just
deleting them from the release branch. The poms in the modules
and samples directories refer to these unreleased things and
these would need to be changed in the release branch to match the
deletions. Currently these pom changes aren't being done and this
is why the source and binary distributions don't match (see
TUSCANY-3678). Instead there is complex and error-prone code
in the distribution assembly files to exclude one set of things
from the binary distribution and a different set of things from
the source distribution.
This discussion has convinced me that we should fix TUSCANY-3678
in 1.6.1 by deleting all the unreleased modules and samples from
the release branch and updating the poms and distribution assembly
files in the release branch to match these deletions. The modules
and samples to be deleted should be all those that weren't included
in the 1.6 binary distribution.
I'll check in these changes to the 1.6.1 branch over the weekend
unless there are any objections. This will allow us to see what the
1.x trunk would look like with the unreleased things removed. In
parallel to these 1.6.1 changes we can continue this discussion
about the best way to handle the unreleased things within the
1.x and 2.x trunks.
Simon
