I think you have to be willing to backport
changes to your release build. For instance, every year I make changes
to maintenance stream builds to account for
1) Other projects that have deleted
their repositories (no retention policy)
2) Projects that have moved in source
3) Archived builds
This means that a release build is not
really reproducible for very long. However, I just branch my release builder
to a maintenance stream and continue.
We could ask teams to put their child
repos in their release repositories before the release date, but not link
to them via the compositeArtifacts.jar and compositeContent.jar files.
This would allow you to build by specifying the child repo directly while
avoiding an early Indigo release to consumers. However, I don't think this
approach would give us much more time before the inevitable need to modify
your build to account for other changes.
Cross project issues
06/08/2011 02:45 AM
Moving p2 repos on release day!
I noticed an issue with the policy of moving p2 repos on release day. It
breaks reproducibility of builds for me.
Currently, I'm building using a target definition. The target definition
defines a set of p2 repos we build against. For RC4 I had to update an
entry to point to a temporary location called "RC4". This will
removed on release day. Scanning through the list of entries I also
noticed that some p2 repos will likely be purged after the release
anyway because say contain milestone builds. Thus, after release day the
target platform will be useless and my builds won't be reproducible
I was wondering if this is a good practice. It doesn't feel so. I think
it would be better if I can make a final build using the final p2 repos.
But this means that all the repos exists in their final location.
How do you ensure reproducibility? The only option I currently see is to
go through my target definition again *after* release and update all the
entries in hope that the p2 repos didn't change and my build will be