[EMAIL PROTECTED] escribió:
> Jon Stevens wrote:
> >
> > on 1/14/01 3:46 PM, "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> >
> > > They are called dependencies. There is NO way we can have a global build
> > > system
> > > without using CVS tags for supported versions. If Jetspeed it forced to work
> > > out of the Turbine HEAD all the time then this is not going to work. Things
> > > will be failing left and right.
> > >
> > > Kevin
> >
> > Jetspeed makes a release which should be able to depend on a specific
> > version of Turbine. Right now, we all agreed to make that based on TDK
> > releases by tagging Turbine with the TDK.
> >
>
> Done now, with a little delay due to "real work".
>
> > However, the CVS HEAD version of Jetspeed should always be working against
> > the CVS HEAD of Turbine. Period. Either way, you are going to have to make
> > the changes to be compatible with Turbine (or whatever other dependency you
> > have) on the next release.
> >
>
> I'm not sure I agree with this statement because tracking these kind of
> dependencies used to require a huge involvement in the dependent project
> in order to follow the changes.
>
In the case of turbine this is possibly true. But there are degrees of dependency. I
think
it is not so true in the case of castor, xerces, etc. it is even less true for
auxiliary
jars, like postgresql or mysql (are you also asking for functional interoperability
with
latest cvs version of databases?
>
> Now that we have a tinderbox, we still have 2 options:
> - use "reference point" for the dependency on other projects (like Turbine TDK jars)
> and update the dependency on every update of the reference point (something which
> we haven't done with Castor)
> - update the reference point whenever the Tinderbox detects an incompatible build or
> whene a new reference point is released) in order to make the CVS HEAD always
>buildable
> against the other projects CVS HEAD.
>
> I can see 2 limitations currently to the second solution:
> - since we include the other projects jar in CVS that would require a lot of CVS
>updating
> of the jars. In order to make it practical, we need a CJAN to automatically fetch
>the
> latest version and remove the included jars from the given project.
> From what you said this is in the works.
> - even if the HEAD are buildable against each other, this does not guarantee that
>they
> produce *functional* code. There must be a standard test suite used in all the
>projects
> in order to guarantee functionality (like make tests for Perl).
> Is there any work done on this ? Which mailing-list should I subscribe for that ?
>
+1 on your concerns.
While I understand that it is important for integration to be able to minimise the
constraints imposed by version dependencies, I think that "daily" compatibility comes
at the
price of poor compromises to tackle with api changes or functional problems. I don't
think
this ammount of pressure is necessarily good.
>
> --
> Raphaël Luta - [EMAIL PROTECTED]
> Vivendi Universal Networks - Services Manager / Paris
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
