On 03/22/2016 06:20 PM, David M Williams wrote:|
I'll give advise on
part of what you say.
If you use use Hudson then for
it might suffice just to point people to
(or, whatever it is called). That assume not too many people
would be "getting"
those. (Since Hudson is not optimized for lots of downloading).
Then, if you are literally "at
Eclipse" you might want an /integration and/or /milestone
that matched the I-build or milestone of "Eclipse codebase" you
were building against.
/release I would call "/releases"
assuming you will have more than one. Which brings me to the
of my advice. You say "Each of these
just get the latest". But
you want to be careful not to remove, and replace one repository
For several reasons. 1) There is a generally an expectation (at
Eclipse) that "releases" are retained for a long long time (if
not "forever") just because someone may be building on *your*
release, and have some update or maintenance to make in years to
2) Especially for "releases" but even "integration"
or "milestones" there is an assumptions that p2 repositories
are immutable. 3) An easy strategy to accomplish a little of
(short URL and immutable repositories) is to use composites, so
would have under it "release1" but also, eventually "release2",
etc. You can have "composite" metadata just under "/releases"
to "combine" the releases if you'd like. One advantage of that
approach, even for "snapshots", or milestones or what ever is
that if a user (or, "builder") is using one repository, they
will continue working as you put a new one in place and then add
Otherwise, there is a risk what ever they are downloading will
I'm getting close to the point where I really need to
understand this, so I'll try to ask more specific questions.
I'm not too concerned about the SNAPSHOT repo, although we do have
to get that working to some extent. The releases repo is more
important to get correct out of the box.
For this project, when I release a new version, I don't expect to
support previous versions. It may make sense for old releases of
the Eclipse IDE to be available for a time after newer releases
come out, but I don't see a reason to support that strategy for
this application. I would just like to provide a single release
URL, and the latest release will be available there.
"David M. Karr"
Tycho user list
03/22/2016 07:39 PM
Strategies for defining update site url
I'm working on an Eclipse plugin codebase, and
gotten to the point
where the build server is producing the update site zip file.
need to think about reasonable strategies for defining an
URL. The simplest strategy would be a single URL that I
everything to, snapshots and releases. That's probably not a
Is it as simple as just defining a "/release" url and a
and leave it at that? Each of these would just get the latest
or snapshot respectively.
Obviously, I have to work with my infrastructure team to make
available, I just want to start with something that will be
tycho-user mailing list
To change your delivery options, retrieve your password, or
from this list, visit
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit