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?
>
> > > 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).
> I think we will have to change some parts of C2 before the final release
What do you have in mind here?
> and it might be difficult to maintain this.
Why do you think it is difficult to maintain? Because of branching?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
