> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
>
> > > Giacomo Pati wrote:
> > >
> > > Here we are to see how the issues are:
> > >
> > > On Fri, 18 May 2001, Carsten Ziegeler wrote:
> > >
> > > > I think we agreed on the following changes:
> > > >
> > > > 1. map namespace for parameters (changes the sitemap definition)
> > > > Volunteer: Sylvain
> > > > Finished : 22rd May
> > >
> > > done
> > >
> > > > 2. Optional SAXConnectors (changes internal content aggregation)
> > > > Volunteer: Carsten
> > > > Finished : 23rd May
> > >
> > > done
> > >
> > > > 3. Redesign of the EntityResolver/URL handling
> > > > (changes the pipeline components interface)
> > > > Volunteer: Carsten
> > > > Finished : 23rd of May (hopefully)
> > >
> > > done (?)
> > >
> > The major part is done. Regarding a beta version this is OK.
> > There are some minor issues if we want to add the cocoon: urls,
> > but hopefully this doesn't affect any interfaces.
> > So we could regard this as done.
> >
> > The fix for the TraxTransformer is finished, but currently
> > my cvs is not working properly, so i can't check in.
> > Hope I can solve this today...
> >
> > > > 4. Remove the X/CIncludeSAXConnectors and make transformers
> > > > Volunteer:
> > > > Finished :
> > > > This transformers are not really required for the beta, I think
> > >
> > > outstanding, not relevant for beta (?)
> > >
> > Yes, I will (if cvs is working) remove the X/CIncludeSAXConnectors
> > and readd the NullSAXConnector. Then this is solved for the beta.
>
> IIRC there has been a veto from Berin to this. As long as we don't have a
> Tranxformer replacing this functionality he needs it. Berin?
>
Ups, I didn't see that veto. Ok, lets wait for this..
> >
> > > > 5. Parameters for Matchers/Selectors (I think there was no vote
> > "-1")
> > > > (changes the pipeline components interface)
> > > > Volunteer :
> > > > Finished :
> > >
> > > done
> > >
> > > > 6. Change the Namespace for the taglibs to the standard
> > > > Volunteer :
> > > > Finished :
> > >
> > > done
> > >
> > > > 7. Administration tasks for making the release
> > > > Here we should collect what has to be done.
> > >
> > > This should be discussed. My questions (still) are:
> > >
> > > - how should the dist be structured?
> > >
> > > As I've already explained the build target "dist" has all the jars
> > > twice in final tgz/zip file this is a duplication amount of about
> > 8MB
> > >
> > Personally I am not sure about the dist, because this is then a prebuild
> > version for the servlet api 2.2. The users have to rebuild for the
> > servlet
> > api 2.3 and if they want to use additional features, e.g. php, j2ee.
> >
> > So can't we simply pack the cvs tree as the distribution?
> >
> > > - how should further development take place concerning cvs tagging
> > >
> > > a)
> > > +- V2_0B1
> > > !+- V2_1_dev
> > > Vv
> > > -------+---------------------------+--------------> HEAD
> > > ! A
> > > ! +- V2_0B2 +- V2_0RC1 ! Join
> > > ! V V !
> > > +---+----------+------------+ V2_0
> > >
> > > b)
> > > +- V2_0B1 +- V2_0B2 +- V2_0RC1 +- V2_0
> > > V V V V
> > > -------+----------+----------+-----------++-------> HEAD
> > > ! A
> > > ! ! Join
> > > ! !
> > > +----------------------------------+ v2_1_dev
> > >
> > > c)
> > > +- BETA1 +- BETA2 +- RC1 +- REL_2_0
> > > V V V V
> > > -------+----------+----------+--------+-----------> HEAD
> > >
> > > Comments to the variations above:
> > >
> > > a) The advantage of a this approach is that 2.1 development can
> > > start as soon as the beta1 is out. The disadvantage is that we have
> > > to deal with a separate branch for the 2.0 release.
> > >
> > > b) This is the revers of a). The head branch is always in synch with
> > the
> > > latest announced release and 2.1 development starts on a separate
> > > branch instead on the head branch.
> > >
> > > c) The advantage of this approach is its simple straight way of
> > release
> > > handling. On the other hand development of a 2.1 release can not be
> > > started until the 2.0 release is out.
> > >
> > Although we can't start with 2.1 before we released 2.0 it is easier to
> > maintain, so I vote +1 for c).
>
> Why can't we start with 2.1 on the main branch and have the beta
> in a side
> branch? If we aggree that the functionality of the beta1 is what
> will be in the
> final release I don't see any problems? Bugfixes can be joined
> into the main
> branch from time to time (if I understand CVS correctly).
>
Yes, this is correct. But it might be that we have to add some
feature - don't ask me now which one - and that could be a little
bit harder to maintain.
> > I think we will have to change some parts of C2 before the final release
>
> What do you have in mind here?
>
The only thing I have in mind is the cocoon: url. If we agree that all new
features inlcuding the cocoon: url are only available from 2.1 on, ok this
makes it a lot easier. and we could do exactly that.
> > and it might be difficult to maintain this.
>
> Why do you think it is difficult to maintain? Because of branching?
>
Yes, exactly. I personally don't like branching and joining as there
are always complications with it. But on the other hand we are enough
excelent developers who will take care of this.
OK, you have persuaded me. Then we should vote between a) and b)
correct?
So a) might be the solution to go.
Carsten
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
