Hi
Ah! That corresponds to what I observe and am always puzzled by. Given
that the previous installations are fully available in the
features/plugins folders, why is it necessary for a reversion to do any
remote access at all? At best it wastes time, at worst it fails.
Regards
Ed Willink
On 10/12/2019 15:18, Camille Letavernier wrote:
Hi Jonah,
IIRC (from a few years ago :) ), one of the reasons to keep multiple
versions in the Simrel Composite was to support rollback. If you
updated e.g. from M1 to M2 and noticed that something's broken, you
can revert to M1 automatically (Via Installed Software -> Installation
History). However, this feature only works if M1 is still available at
the same location, i.e. in the composite update site you used to
update to M2 (Or to initially install M1).
That was even more useful when we had yearly releases, because users
could be affected by SR1 regressions and want to rollback to the "SR0"
release (M1 and M2 only affect Eclipse developers and early adopters,
so it's typically less of an issue).
Regards,
Camille
On Tue, Dec 10, 2019 at 3:39 PM Jonah Graham <jo...@kichwacoders.com
<mailto:jo...@kichwacoders.com>> 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
<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
--
Camille Letavernier
Senior Software Architect EclipseSource France
Email: cletavern...@eclipsesource.com
<mailto:cletavern...@eclipsesource.com>
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
EclipseSource France SAS 7 rue de la Croix Martre 91120 Palaiseau
General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516 00015 R.C.S. EVRY
_______________________________________________
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
