> ... that update site will be removed after about
a month according
> to the retention policy.
I guess that document isn't very clear,
but actually, all M-builds, and RC's will removed "right after"
(or, slightly before!) the actual release day (2/27). Sort of. We actually
do leave "the last M-build" in the 4.4-M-builds repo in case
we need to do "post-release" fixes and builds (we need it for
the "comparator" to work) but we see that as an internal "implementation
detail" and after we've started such post-releases fixes (and have
new "post release M-builds") there is no guarantee the "the
original" would be left in place indefinitely, and it could be removed
at any time.
> Would it be possible to retain the RC4 builds
> that downstreams RCPs can consume the latest platform and continue
I see the problem, but don't think we
can or should change the retention policy for this. Seems it would result
in "indefinite duplication", confusion, be a source of errors,
and extra work to maintain. If the PMC feels differently, I'd take direction
from them ... but, would prefer that we find a better solution or "suffer
through it". Changing the policy does have some implications for "use
of Eclipse Foundation resources" which may seem minor for "one
case", but could have large implications if the practice was wide
> If not, do you have a suggestion on how to achieve
I don't have a good solution for all
cases, but some tips that might help some cases (and, perhaps other people
know of other technical solutions?):
- Depending on the build setup, repositories
are sometimes defined in "variables" in the parent pom, so these
can be overridden on the commend line.
- I do not think that helps if you are
talking about a literal "*.target" file. As far as I know, "variables"
can not be used there, in Tycho or PDE. Nor, as far as I know, can the
whole "target file" be a variable.
-- In this case, the only thing I know
that might help is to wait to do your "final tagging", until
we have our "final repo" defined (which happens early next week,
though it not "visible" in the composite repo until release day)
so you can update your .target file with that, before your final tagging.
And, you just have to trust (or, trust but verify :) that the bits are
-- Other than that, I don't know of
a solution, unless you have a branch (or tag?) for "post-release"
builds? For simple cases, a few modifications with a new tag might
be enough (assuming you'd made no other changes). For complicated cases,
I'd recommend a branch, since some projects have to do "post release"
fixes anyway, for "Long Term Support", and updating prerequisite
repositories is a common issue there, in "long term support"
(some projects, move their repositories to "archives" for example).
If readers of this list have other technical
solutions (where we can change something in the Platform to help), please
open a bug in Eclipse, Platform, releng.
If anyone wants the PMC to change the
policy, a bug in Eclipse, Platform, PMC would be the place to open it.
Also, while this post is about "long
term retention", if anyone ever has a need for extending "short
term retention", that's another matter, and then we'd try to be accommodating
... for example, if anyone has a "product release two weeks
after our release, and would like something retained for an extra few weeks,
please open a bug in Eclipse, Platform, Releng, and I'd consider
those requests on a case-by-case basis -- but would try to be accommodating
to short term requests. I know of other projects/products for example,
that have said (to other projects) "we have a demo for xyz conference
in 1 month, that is based on xyz I-build ... could you retain that for
a an extra month, in case we need to do some last minute fixes and re-builds).
But, again, this is a different topic, than the original long term retention
02/20/2015 01:59 AM
Update Site Retention Policy issue? (Building an RCP as part of the release
We have a RCP called Trace Compass that we intend to release as part of
the release train. If we take Luna SR2 as an example, in our git repo,
our target has to point the 4.4-M-builds/M-4.4.2RC4-201502041700 update
site so that we can consume the platform that will be released for SR2.
However, that update site will be removed after about a month according
to the retention policy . This means that our tag in git will not
build anymore when checked out in a few weeks. One option would be to do
the build on the release day with the updates/4.4 site and tag then but
this is really not ideal and goes against the spirit of having offsets
in the release train. Would it be possible to retain the RC4 builds so
that downstreams RCPs can consume the latest platform and continue to
build? If not, do you have a suggestion on how to achieve this?
Thank you for your help,
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipse-dev