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
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
--
Senior Software Architect
EclipseSource France
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@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
|