Re: [eclipse-dev] Update Site Retention Policy issue? (Building an RCP a

[David M Williams <david_williams@xxxxxxxxxx>]

> ... 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 so
> that downstreams RCPs can consume the latest platform and continue to
> build?

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

> If not, do you have a suggestion on how to achieve this?

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 the same.
-- 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 posting.

Thanks,

From:        Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
To:        <eclipse-dev@xxxxxxxxxxx>,
Date:        02/20/2015 01:59 AM
Subject:        [eclipse-dev] Update Site Retention Policy issue? (Building an RCP as part of the release train)
Sent by:        eclipse-dev-bounces@xxxxxxxxxxx

---

Hello,

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 [1]. 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?

[1] https://wiki.eclipse.org/Eclipse_Project_Update_Sites

Thank you for your help,
Marc-André Laperle
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev