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
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>
On Tue, 10 Dec 2019 at 03:40, Mikael Barbero
<mikael.barb...@eclipse-foundation.org
<mailto:mikael.barb...@eclipse-foundation.org>> wrote:
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 thedownload.eclipse.org
<http://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
See also this FAQ entry
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ#Why_do_we_use_composites_anyway.2C_if_there_are_potential_problems_with_them.3F
Cheers,
*Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
📱 (+33) 642 028 039 | 🐦 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for
Open Innovation and Collaboration
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
