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?
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.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
