I'm OK with all of this. I believe the implication (not stated explicitly)
is that everything in "modules" needs to be included in the main build.
I think this should be a requirement, and anything that isn't ready for this
should be under "contrib".
Also, I'm not sure how this affects the contents of "samples". I just
came across two recently added 1.x samples that aren't in the build, and
one of these can't be added to the build because it isn't buildable.
I think we should treat "samples" in the same way as "modules", which
would suggest the following structure:
trunk
modules (for release, all in the build)
samples (for release, all in the build)
etc.
contrib (excluded from release profile)
modules (not for release, some in the build)
samples (not for release, some in the build)
etc.
Simon
Simon Laws wrote:
Good ideas Raymond. Small comments in-line
On Thu, Jul 1, 2010 at 8:11 AM, Raymond Feng <[email protected]> wrote:
IMO, we could have the following categories:
1) Sandbox: crazy ideas or something that don't have consensus yet in the
community (You can do whatever you want here :-)
+1
2) Trunk/contrib: experimental features that are not ready to be included in
the next release
a) If the code can be built, the module should be included in the main
build
+1 at the discretion of those working on the module. I.e. if it builds
but you want to exclude it then no problem.
b) if the code cannot be built, the module won't be included in the
main build
+1
3) Trunk/modules: stable features that are ready for the next release
+1
Developers can adjust things between 2.a and 2.b.
+1
We should promote things
from 2 into 3 when the features are ready.
What does "we" mean here. Presumably developers working on modules can
do this when they feel ready.
We should always try to ensure the features included in the build passing no
matter if they are from "contrib" (2.a) or "modules" (3). The default maven
build profile should include both "contrib" and "modules". The release
profile will exclude "contrib". When we cut a release, the "contrib" will be
excluded from the distro.
+1
Mostly, I prefer to have a "SOFT" separation between the experimental and
ready-for-release features.
Me too.This kind of approach at least gives the developer the ability
to develop in the trunk while giving the RM a clear steer on what is
in the distro.
Sent from my iPhone
On Jun 30, 2010, at 10:47 AM, Simon Laws <[email protected]> wrote:
Simon
