build stable <-- only stable stuff build unstable <-- stable and unstable build webapp <-- only stable stuff
Or better:
configure stable <-- only stable stuff configure unstable <-- stable and unstable configure webapp <-- only stable stuff
That way, it isn't much work to get the unstable stuff, but you've got to ask for it.
Upayavira, who's busilly trying to catch up with cocoon-dev.
Mark Lundquist wrote:
On Apr 1, 2004, at 9:35 AM, Joerg Heinicke wrote:
On 01.04.2004 15:00, [EMAIL PROTECTED] wrote:
+ ! Exclude unstable blocks from the default build + + Edit the blocks.properties file and exclude all unstable blocks. + Since it's a release they should not get compiled by default.
What about a vote on this? I'm -0.1 on excluding unstable blocks by default.
If my vote counted, I'd give -1 to default exclusion of unstable blocks. Still undecided about unstable blokes :-)
The rationale for default exclusion seems to be: "You have to ask for it in order to get it, because if you asked for it then it's more likely that you at least know that its status is something called 'unstable' (and you might even understand what that means)". But I've yet to see a clear case for why that's so frigging important :-). Why are unstable blocks something users need to be warned off of? The "unstable" phase is crucial for developing momentum for the coolest stuff in Cocoon, and the key to that is exposure, and the key to that is samples getting built by default. Get people hooked on the cool stuff when it's still unstable — that's what creates critical mass for getting it good enough to be stable! (Here I'm paraphrasing, or maybe expanding :-), on a point Ugo made the other day).
There are really two "default" Cocoon configurations I'm interested in: (1) a minimal configuration, for adding things to to build my production Cocoons, and (2) the full monty, Cocoon w/ all blocks and samples, so that there's nothing I can't see and try out. Default inclusion/exclusion has only to do with how much work it takes me to get to either of those configurations — for me it has nothing at all to do with stable/unstable status.
What I really want is a dead dog simple way to say "build full", but let "local.whatever" (I guess) take care of whatever I consider to be "minimal", which is really not "minimal" at all but is rather precisely what my production needs require.
What I think I really, really want, is to be able to unpack the distro in one place but then build multiple, differently-configured cocoons from the single instance of the distro.
And Vadim is working on th refactoring of the blocks samples page in dependency on the stable/unstable status.
+10... maybe partition it into stable / unstable / deprecated.
My $.02... ~ml
