SNAPSHOTs

[Jeremy Boynes <jb...@apache.org>]

sissonj@insession.com wrote:
> 
> To be able to do this effectively, we would need a tool that tells us when 
> there is a newer version available in a remote repository.  When a newer 
> version is available, a developer (or a continuous integration tool) can 
> change their local copy of the code to use the newer version and test 
> compatibility with that version and if all is ok, commit the change. 
> 

I think the problem we are seeing is more due to uncontrolled SNAPSHOTs 
rather than the concept itself. For example, a lot of the problems we 
see go away when OpenEJB is rebuilt. This implies two things:

1) there is too much coupling between the projects

2) when changes are made new jars are not posted to the online repo
    quickly enough, combined with the performance of the online build
    being so slow that people are building offline and don't see new
    versions even when they do get posted

The first of these will require time to solve.

One of the factors with the second is the number of repo locations 
(because developers do not have write access to a central repo) and the 
unpredictable performance of the main repo at ibiblio. By moving to one 
central repo with good performance I believe we will address both of these.

> Currently, all developers are exposed to updates to SNAPSHOTS and 
> sometimes the build can be broken for days.  If you don't have a backup of 
> your previously building code (and repository?), one is in trouble if they 
> want rebuild (e.g. an offline build) a working version.
> 
> I haven't thought this through too much, but have never felt comfortable 
> with SNAPSHOTs.  Could versioned dependencies help us here?
> 

The problem I think we will run into is an overabundance of versions - 
at the extreme one for every commit. That is the problem that SNAPSHOTs 
were intended to solve by allowing one shared version that could be 
overwritten combined with an automatic download mechanism.

Now that we have a central way to change the project version, one option 
might be for developers to work with a "DEV" version that never leaves 
their local machine. Because this is not a SNAPSHOT we would eliminate 
the continual polling of the remote repo for artifacts that are being 
built allowing for an online build that would pick up new third 
party/sister jars. The committed version number would be SNAPSHOT so 
that the automated build process (or anyone working with a fresh 
checkout) would see the latest version which is known to have built (ok, 
is supposed to have built).

A developer may get in trouble if they have a lot of uncommitted work 
and someone posts a new snapshot. Hopefully that would get fixed by an 
svn update and rebuild; if not, there are likely to be conflicts that 
need to be resolved anyway. This problem is of course reduced by 
committingn frequently :-)

The big upside though is that this should make the build more reliable 
for end-users.

--
Jeremy