Lloyd Chambers wrote:
Harsha,
I expect I will need to make more HK2 changes/additions as V3
development progresses, so this will be an ongoing issue.
One option is for HK2 to become part of V3. Another is to document
exactly what must be done for a seamless push of HK2, preferably
automated without any voodoo.
For last weekend's fun, an API (interface) change meant that HK2 and V3
needed to change in sync.
Why?
Why can we not do the following:
- Suppose that the current version of hk2 is 5.6.0 (it's not, but
that's OK)
- V3 should depend on hk2 versions [5.6.0,5.7) (in case we don't
trust backwards compatibility. If the change is truly backwards
compatible, version [5.6,) should be fine. Note that backwards
compatibility also implies that we have a clean
interface/implementation separation, which is probably not true for
every module)
- hk2 modified an API, so it should rev to 5.7.0 (change minor
number for a backwards-compatible API change)
- hk2 publishes 5.7.0 (this should be done by RE), but NO ONE else
uses it yet (or they can if we are confident of backward compatibility)
- The integrator of hk2 then updates their dependency (in their
workspace only for now) to 5.7.
- The integrator makes the changes and tests them. (the testing is
aided once we move to mercurial, because we can trivially branch and
run tests automatically using Hudson).
- When the integrator is satisfied, they commit the changes.
- Now anyone that picks up the latest v3 gets the changes, and now
fetches hk2 5.7. Anyone that does not pick up the latest can happily
use the older version.
Co-ordination is needed ONLY between the hk2 supplied and the
integrator of the hk2 changes
into v3, and NO ONE else should see the change until it is complete, or
break on an intermediate
stage. So long as step 7 is atomic (and it should be with any
reasonable SCM system), this should
be seamless and invisible (rather the opposite of what happened last
week). We also need to
fix the horrible network and machine problems we have (couldn't publish
to java.net, builds fail when a repository
is off line, not always sure that all copies are the same, different
machine environments
give different results, and artifact coordinates seem to not always be
unique).
This is a reason why we should NOT use SNAPSHOT for separately
delivered modules.
I suspect we should eventually migrate from one monolithic build and
repository for V3 to several (5-10?)
smaller repositories that individually deliver versioned modules which
are assembled into
a GFv3 release (of whatever form). This will be more desirable once we
move to mercurial,
because mercurial does NOT support partial checkout of a repository.
Also note that the hk2 developer can make the change, test, and publish
it at ANY TIME.
Someone else can integrate the change (say) a month later, and
everything still works.
Ken.