Re: [tycho-user] Understand choices and strategies for composite update

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hi David,

One idea would be to use composite repo (as your subject suggests),
https://wiki.eclipse.org/Equinox/p2/Composite_Repositories_(new) set
up as follows:

http://site/p2/ <-- main update site, composite of all subdirectories
/p2/v1.0/ <-- 1.0 version, composite of all "compatible" releases with 1.0
/p2/v1.0/v1.0.1 <-- actual release p2 site
/p2/v1.0/v1.0.2 <-- future compatible release that you want
conservative user to upgrade to
/p2/v2.0/  <-- 2.0 version, composite of all "compatible" releases with 2.0
/p2/v2.0/v2.0.1 <-- future release p2 site,

This allows users to focus on which ever level of risk and upgrading
you want. If they want to limit to a specific version, then use the
longest URL, if they want whatever is latest, use the shortest. Then
you have the secondary decision of what update site you include in the
product when you ship/install it.

Regardless of your approach, I personally am a big fan of composite
repos because it allows each individual build to be independent, both
in its creation and later in accessing it for end users or extenders.

BTW Eclipse IDE has struggled to answer spme of these questions for
many years. i.e. should Eclipse 4.5 (Mars) upgrade to 4.5.1 (Mars.1)
and 4.5.2 (Mars.2) only, or should it also upgrade to 4.6 (Neon). So
the issues you are struggling with are not simply solved.

Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 3 June 2016 at 21:08, David M. Karr <davidmichaelkarr@xxxxxxxxx> wrote:
> I'm working on an Eclipse plugin codebase that's built with Tycho, and we're
> getting close to a first release.  The update site that the build produces
> looks ok.  The plugin produces four features that are all underneath a
> single top-level container. When I test the update site in Eclipse, I can
> check the top-level folder, and it properly installs all four features.
>
> If we were to keep it this way, when we produce a new release in the future,
> it will have a new version number, but the structure would be the same.  New
> users could install the new version, and users with the old version would
> get the update.
>
> What if we wanted to allow for users to choose to install an older version
> than the latest?  This won't be meaningful until we're ready to release the
> next release after this, but I want to understand our choices so we can plan
> for it.
>
> It doesn't seem reasonable to build this "multi-version" structure into the
> build process for the application, it seems like this is more like a
> "post-build" process.
>
> Is there documentation and examples for building this kind of structure?
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tycho-user