Hi David. Thank you for your helpful reply! Comments inlined.|
On 2015-02-20 12:20 PM, David M Williams wrote:
> ... that update site will be removed after
a month according
> to the retention policy.
I guess that document isn't very
but actually, all M-builds, and RC's will removed "right after"
(or, slightly before!) the actual release day (2/27). Sort of.
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
detail" and after we've started such post-releases fixes (and
new "post release M-builds") there is no guarantee the "the
original" would be left in place indefinitely, and it could be
at any time.
Thank you for the details, that's good to know!
> Would it be possible to retain the
> that downstreams RCPs can consume the latest platform
I see the problem, but don't
can or should change the retention policy for this. Seems it
in "indefinite duplication", confusion, be a source of errors,
and extra work to maintain. If the PMC feels differently, I'd
from them ... but, would prefer that we find a better solution
through it". Changing the policy does have some implications
of Eclipse Foundation resources" which may seem minor for "one
case", but could have large implications if the practice was
I understand. I was thinking more in the line of a symbolic link, if
size is a concern. But I understand that this is already more
maintenance and you can't accommodate all use cases.
> If not, do you have a suggestion on
how to achieve
I don't have a good solution
cases, but some tips that might help some cases (and,
perhaps other people
know of other technical solutions?):
- Depending on the build
are sometimes defined in "variables" in the parent pom, so
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,
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
though it not "visible" in the composite repo until release
so you can update your .target file with that, before your
And, you just have to trust (or, trust but verify :) that
the bits are
Oh, I didn't know that you had a final repo a few days before
release, that's good to know. That means we could tag the commit
that we contributed to simrel then later make a commit in a
maintenance branch pointing to the final repo in time for the
-- Other than that, I
don't know of
a solution, unless you have a branch (or tag?) for
builds? For simple cases, a few modifications with a new
be enough (assuming you'd made no other changes). For
I'd recommend a branch, since some projects have to do "post
fixes anyway, for "Long Term Support", and updating
repositories is a common issue there, in "long term support"
(some projects, move their repositories to "archives" for
I think we'll go the branch route. I seems like the safest. We can
document that the tags might not necessarily build at a later date
but the maintenance branch will most likely build. Also that way,
the build qualifier of our plugins will match what we contributed to
the simrel so that's a good thing!
Again, thank you for your help!
If readers of this list
have other technical
solutions (where we can change something in the Platform to
open a bug in Eclipse, Platform, releng.
If anyone wants the PMC to
policy, a bug in Eclipse, Platform, PMC would be the place
to open it.
Also, while this post is
term retention", if anyone ever has a need for extending
term retention", that's another matter, and then we'd try to
... 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
those requests on a case-by-case basis -- but would try to
to short term requests. I know of other projects/products
that have said (to other projects) "we have a demo for xyz
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
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
site so that we can consume the platform that will be
released for SR2.
However, that update site will be removed after about a
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
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
Thank you for your help,
eclipse-dev mailing list
To change your delivery options, retrieve your password,
from this list, visit
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit