On 03/23/2016 12:32 AM, Mickael Istria wrote:
On 03/23/2016 12:39 AM, David M. Karr
wrote:
I'm
working on an Eclipse plugin codebase, and I've gotten to the
point where the build server is producing the update site zip
file. I now need to think about reasonable strategies for
defining an update site URL. The simplest strategy would be a
single URL that I publish everything to, snapshots and releases.
That's probably not a good idea. Is it as simple as just
defining a "/release" url and a "/snapshot" url and leave it at
that? Each of these would just get the latest release or
snapshot respectively.
Obviously, I have to work with my infrastructure team to make
the URLs available, I just want to start with something that
will be maintainable.
If you use Nexus and the unzip plugin, then you have those
repositories available on simple "mvn deploy" of the p2 repository
artifact, and having a release is similar to "mvn deploy" but
having the -SNAPSHOT removed in the version of the p2 repository.
About specific URLs, here is my recommendation, used by some
Eclipse.org project. Those assumes you're maintaining a SINGLE
STREAM of your repo, ie there is master but you don't work on
branches.
* /snaphots : contain the latest build from master, can be
published by a Maven build step or CI
* /releases/ : publishing to releases is a manual step: take a
snapshot build, verify it's working and copy its content to the
named release folder
** 1.0.0/
** 1.0.1/
** 2.0.0/
** ...
** latest/ latest can either be a composite to the latest
version, or a simple copy of its contents.
Some other projects have set up different approach either because
they work on different streams simultaneously (so that there are
multiple "snapshots"), or because they have some intermediary
quality-level (staging, integration...). If you don't need those,
keep with the simplest approach possible for you, since
over-design on that part actually becomes boring and costly to
maintain.
I'm finally getting to the point where I need to focus on this, so I
have some more specific questions.
I need to understand more about the Nexus unzip plugin and that part
of the process. I'll pursue other channels for that information.
So concerning your URLs suggestion, I assume that this means that if
I'm releasing a version "2.0.1", say, then I'll assume that we'll
prepare a folder where we're hosting the update site named "2.0.1"
and configure Nexus to unzip the deployment there. We would then
advertise that "http://.../ourapp/2.0.1" is the update site for this
release. Is that correct? Or can we have a "static" update site
URL, and that when we deploy the new release to it, when users
attempt to update an existing installation, they'll get the new
release? I would think something closer to the latter is more
reasonable.
HTH
_______________________________________________
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
|
