Raphaël Luta wrote:
>
> 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)
It is my hope that the "business as usual" case is that projects like
JetSpeed will work with a range of versions of their dependencies. This
should generally include the latest released version of the dependency and
the current head version of the dependency. As a general rule, people who
build projects that they want others to depend on need to build and depend
on need to take great care to schedule their interface changes and
deprecate prior interfaces for a period of time instead of simply removing
them.
In the hopefully rare cases where it is not possible to build against both
versions, a judgement call needs to be made as to which one to go with.
Generally, this needs to be done on a case by case basis, and typically
would be based on how close each product is to release.
> - 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.
If the goal is to support a limited range, then the ideal would be that the
reference point be the stable end of this range. This isolates developers
from day to day fluctuations and bugs in other projects that may occur from
random snapshots.
However, the current state with respect to Castor is an example of what
should not be done. Not supporting either the head or latest release is
not good.
> 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.
Per the dicussion above, I don't see the need for the churn.
> - 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 ?
I would gladly add the execution of tests to the tinderbox runs. What
tests are appropriate are generally a project by project decision.
- Sam Ruby
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
