The snapshot build I use are not made to be reproduceable. The snapshot builds are performed by a continuous build that is there to test (automatically) the integration of all modifications. It is there to detect very quickly any regression.
I sometimes have used some sort of build "promotion". With ivy, what I did was to promote a set of jars (of different project) from one repository to an other. The continuous build is building one sub-project at a time, and put the jars on a local repository. At the end, if all subprojects have build (= +/- tested) successfully, the result is promoted to a share repository. By doing I know that the jars in the share repository are "compatible". The share repository is available for the developpers that don't want to have all subproject build in their IDE. In practice, I realised that's rarelly used. I implemented that using a simple install ivy task. I have also some experience with promotion process. But there also, it was not extremelly usefull. In that project, each build had a status, saying up to wich environment it goes. The problem was that this information was useless. Nobody never looked at the status of the build. The only question that was interresting was "which version is currently in which environment". And I think that there are a lot of simple solution to provide the answer (keep a file somwhere with 1 line per environment, or provide something in the code of your deployed application). Finally, my personal advise would be to keep the build promotion separated. Your build should just provide a build number. And you should keep somewhere else the 'status' of that build. My experience is that it is easier for everybody that say "version 1.3.12" than "the verson that was in staging last week". I hope it help. Gilles 2007/1/3, John Williams <[EMAIL PROTECTED]>:
I read about to idea of build promotion at <http://www.jaya.free.fr/ivy/doc/bestpractices.html>, but I can't find any documentation on how to actually do it. Is the best way just to manually edit an Ivy file in the repository to change the status declaration? That sounds easy enough, but the presence of the checksum files in the repository makes me think that editing the ivy files after the fact is frowned upon. Alternatively, does anyone have experiences to share with "snapshot" revisions? My understanding is that every snapshot revision should eventually be replaced by a non-snapshot revision that is identical to the last snapshot, but then what happens to the snapshot revision? Does it just get deleted? Or do you keep two identical revisions with different numbers? --jw
