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
"SNAPSHOTS"
it might suffice just to point people to
"..../last/successful/repository
(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
directory
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
main part
of my advice. You say "Each of these
would
just get the latest". But
you want to be careful not to remove, and replace one repository
with another.
For several reasons. 1) There is a generally an expectation (at
least 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
come.
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
both
(short URL and immutable repositories) is to use composites, so
that /releases
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
to composite.
Otherwise, there is a risk what ever they are downloading will
suddenly
disappear.
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.
HTH
From:
"David M. Karr"
<davidmichaelkarr@xxxxxxxxx>
To:
Tycho user list
<tycho-user@xxxxxxxxxxx>,
Date:
03/22/2016 07:39 PM
Subject:
[tycho-user]
Strategies for defining update site url
Sent by:
tycho-user-bounces@xxxxxxxxxxx
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.
_______________________________________________
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
_______________________________________________
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
|