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
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.
Thank you for the details, that's good to know!
> 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.
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
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.
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
release day.
-- 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).
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!
Marc-Andre
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
_______________________________________________
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
|