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
