Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Strategies for defining update site url

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


Back to the top