Jeremy Boynes wrote:
On Jan 8, 2007, at 9:51 AM, Jean-Sebastien Delfino wrote:
Simon,
I think that what you're describing is a problem only if the jar is
published as xyz-SNAPSHOT.jar without identifying the specific level
of code in the jar. If it is published as xyz-r493223- SNAPSHOT.jar
for example (or another form of identification of a specific level)
then a new revision of the SPI will be published in a different jar
(xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223
will continue to reference xyz-r493223- SNAPSHOT.jar, components that
want to move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
So if I understand correctly, this scheme allows the core components
to move on with changes without breaking the others that depend on
the core. These components become responsible for catching up with
core changes when they wish or can do it (and they better do it
frequently to avoid surprises when they move up levels). Whoever
wants to build a working distribution or run an end to end scenario
becomes responsible for putting the pieces together, and coordinating
and working with the various component providers to make sure that
they all work on compatible levels of the core jars.
Does that make sense?
It makes good sense to me. This is the approach that I was suggesting
in my original post on this topic.
When coupled with releases rather than SNAPSHOT timestamps, yes. You
might want to use an old snapshot temporarily but in general it's not a
good idea.
This works if releases happen frequently enough. The process would be
to develop downstream components based on stable upstream dependencies
where possible. When an incompatible change is made to the upstream
component (making it unstable), the downstream component developer can
either a) move up to the unstable dependency, or b) stay with the
stable dependency. In case a), the SNAPSHOT downstream and SNAPSHOT
upstream components become tightly coupled until they are both released
again. In case b), the SNAPSHOT downstream and SNAPSHOT upstream
components become incompatible until the upstream component is released
again, at which time the downstream component must react to the
incompatible change and produce a new release. This works as long as
everyone understands exactly which components are tightly coupled and
what combinations are incompatible, except in cases such as:
both B and C depend on A
latest A and B are coupled, and latest A and C are imcompatible
someone needs to use latest B and latest C together
I think it would help a lot if somebody who understands this new
scheme better than me could educate us on the steps that the various
people on the project will have to go through when a change occurs in
one of the core Jars.
Generally nothing assuming the changes are generally compatible (80-20
rule). When they aren't, then they need to update their code to react
to the change which is work that would need to be done anyway.
Presumably these issues would show up as a result of running integration
tests after an incompatible change is made to an upstream module. All
the downstream folks would then need to scramble to fix their code to
react to the change. While they are doing this, there would be no easy way
to assemble a working set of compatible components that are more recent
than the last released versions.
Simon
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
