Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Moving p2 repos on release day!

Hi Gunnar

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 control
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.


From:        Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Cc:        "" <>
Date:        06/08/2011 02:45 AM
Subject:        [] Moving p2 repos on release day!
Sent by:


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 likely be
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


Gunnar Wagenknecht
_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top