Hi Adam,
thanks for your interest, I'll try to explain the best I can.
First some facts:
The versioning scheme for artifacts is major.minor.fix.revision, updates on
major and minor can be breaking (interface) changes, the last revision is
mostly for tracking purposes.
There are 4 repositories in play, one local and three remote; snapshot,
release and public.
The scenario:
Initially the content of release repository is
- 'company:moduleA:1.1.2.100',
- 'company:moduleB:1.1.5.200',
- 'company:moduleC:2.1.1.300'
The other repositories, localRepo and snapshotRepo are empty.
moduleA and moduleB both have dependency to moduleC ver. 2.1.1.300
Then two new features are slated for next release, *alpha *and *beta*.
Feature alpha(α) should go into moduleA and beta(β) into moduleB, both
features need supporting changes to moduleC.
In short α->moduleA, β->moduleB, αβ->moduleC.
It is decided that the next version for moduleC containing α and β should be
2.2.0.
Developer A (devA) is going to work on α and developer B (devB) will work on
β.
DevA and devB both check out a branch for moduleC for version 2.2.0
(initially identical to 2.1.1 release), moduleA and moduleB also get new
versions, 1.2.0 (new branches).
When the developers start working they both have to work locally and
integrate the module changes locally, by building and uploading moduleC into
their localRepo.
Now lets assume that devB finishes first and checks in the code for moduleC
and wants to get the changes into the test environment ASAP. For devA this
results in the following repository content:
- localRepo
- 'company:moduleA:1.2.0.350', (~α)
- 'company:moduleC:2.2.0.301', (~α)
- snapshotRepo
- 'company:moduleB:1.2.0.351',(β)
- 'company:moduleC:2.2.0.400',(β)
- releaseRepo
- as before
Now devA doesn't want to get 'company:moduleC:2.2.0.400' into his world
quite yet, since it doesn't have α (only β). Assuming of course that β
doesn't break moduleA.
Here you could of course argue that devA should integrate the changes from
devB in moduleC immediately. But lets assume that he doesn't want to break
his work flow on feature α and wants to delay his integration until
finished.
This means that devA wants artifact in the localRepo to be resolved rather
than getting the artifact from snapshotRepo.
Preventing visibility on snapshotRepo is not desirable I think, because he
might need other artifacts from this snapshot for his integration (there are
other features in other modules wanted for the big release)
This is probably not the best way to go about things, proper modularization
would probably alleviate this problem a lot.
Also this can get the developers in integration headache when the scenario
has even deeper transitive dependencies. But for many of our current cases
this is the way most of our developers want the build to behave (their
locally built copy of the artifact to be used in the integration).
We are aiming for better modularization but there is a lot of work still on
that front.
I hope there are no obvious fallacies in this argument.
If you were able to get through the text unscarred :) I welcome any comments
and suggestions.
gretar
