|
Jonah,
I think one way that a *.target is invalidated is in the case
that one specifies exact IU IDs in a *.target file. Then of
course the specific versions could disappear and a *.target that
previously resolved would no longer resolve (and PDE has a bad
habit of destroying the target platform when there is a resolution
failure). Of course if you point your *.target at a moving p2
target it seems silly to also specify exact versions, so I'm not
convinced that this is actually a good reason. :-P
Also, I'm pretty sure that when you do a rollback, that p2 is
literally rolling back to an older version of the profile that is
actually on disk, and it reuses the artifacts that are also still
on disk. So I don't think rollback requires the artifacts to exist
in the original update site from which they were fetched.
In the end, even if there is a good reason for having 3, or 2
most recent M*, RC* in the train update site, when the release is
made visible, only the R version is present, so that would also
cause whatever problem having 3 or 2 prevents. In addition, it's
always possible to also support a latest composite that does
include only the most recent M*, RC*, R (as well as the EPP site,
preferably the most recent corresponding simple site and is
updated only when those two corresponding things exist). The
clients would benefit (less repos to load) and the server would
benefit (less repos to serve), and the servers benefit results in
a client benefit (the servers are less likely to be slow from
being overloaded).
Regards,
Ed
On 10.12.2019 15:38, Jonah Graham
wrote:
Thanks Ed and Mikael for responding.
I will change to use the staging repo to build &
release my EPP product - I hadn't liked it in the past because
it was a moving target as people updated the simrel contents.
However, I was only referring to multiple children
providing just different versions of the same content - not
composites with different content. There are specific
failures when there are multiple children with the same
content - yet none of the answers or the FAQ answer the
question of the use case of having a single repo with
multiple versions available. However, I don't understand
this line from the FAQ: "and once we remove it, it will
invalidate that target". How does changing the composite to
point from M1 to M2 do that?
Anyway, this seems to be one of the things that are the
way they are - I hope to understand but I am not sure I
will.
Jonah
Can the composite only include the
current/latest version, or can someone educate
me as to the value of having multiple versions?
It's
a really good question. It just seems to be a
"habit" to compose multiple children, usually with
some restriction on the number of children, e.g.,
the most recent n children. But personally, just to
make everything faster for the client and less
overhead for the download.eclipse.org server,
I would prefer to use a repo with a single child
with the most recent version.
So
what prompted everyone to have this habit?
AFAIK, it comes from the simrel process of "making
visible" the repository to the world (after the quiet /
mirroring time). See code comment in https://git.eclipse.org/c/simrel/org.eclipse.simrel.tools.git/tree/promoteUtils/makeVisible.sh#n25
Cheers,
Mikaël Barbero
Team Lead - Release
Engineering | Eclipse
Foundation
📱 (+33) 642 028 039 | 🐦
@mikbarbero
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
