Thank you Camille. I have added your extra information to the FAQ <https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ#Why_do_we_use_composites_anyway.2C_if_there_are_potential_problems_with_them.3F> for posterity. ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com
On Tue, 10 Dec 2019 at 10:19, Camille Letavernier < cletavern...@eclipsesource.com> 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> > 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 >> >> >> On Tue, 10 Dec 2019 at 03:40, Mikael Barbero < >> 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 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 >>> >>> 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 >>> 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 > > > > -- > Camille Letavernier > > Senior Software Architect > EclipseSource France > > Email: 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
