Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build.
Authentication-fw depends on session-fw. This will give me the chance to
test my build system that will
Reinhard Poetz wrote:
I have not tested yet what happens with local changes
after the block is mounted using svn:external. Any experiences?
I've been using svn:external for including the documentation in the
simile.mit.edu web site (which is managed in SVN) importing the /docs
that come from
Upayavira wrote:
Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build.
Authentication-fw depends on session-fw. This will give me the chance
to test my build
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
I have not tested yet what happens with local changes after the block
is mounted using svn:external. Any experiences?
I've been using svn:external for including the documentation in the
simile.mit.edu web site (which is managed in SVN) importing
-Original Message-
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Sent: 18 February 2005 17:41
To: dev@cocoon.apache.org
Subject: Re: Moving blocks
Upayavira wrote:
Reinhard Poetz wrote:
Could some people pls report back whether there have been any
problems on updates
Carsten Ziegeler wrote:
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under
Would it be worth considering adding either 'legacy' or 'deprecated' to
contain blocks that are going to disappear at some unspecified point in
the future (or maybe s/unsupported/deprecated/)? I'm just suggesting
that 'unsupported' may not be strongly worded enough for new users who
start
This makes me a little uncomfortable. So blocks will now have a release
schedule that is independent from core? I'm just wondering if that is a
good thing or a bad thing at this time. And if that is so, why isn't
each block on its own release? (That is just rhetorical, as I don't
believe we
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/branches/
Ralph Goers wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the proposal is to move blocks
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy
to use deployment tool) it should be the goal to have independant
blocks with their own release cycles.
But
13 matches
Mail list logo
