[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[tycho-user] Understand choices and strategies for composite update site?
|
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?
