Bugzilla – Full Text Bug Listing
| Summary: | Graphiti's nightly build overrides itself at the same url | ||
|---|---|---|---|
| Product: | [Modeling] Graphiti | Reporter: | Shenxue Zhou <shenxue.zhou> |
| Component: | Core | Assignee: | Michael Wenz <michael.wenz> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | konstantin, michael.wenz |
| Version: | 0.8.0 | Flags: | michael.wenz:
juno+
|
| Target Milestone: | 0.9.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | Juno M1 theme_release_train | ||
|
Description
Shenxue Zhou
There are two problems with the current approach to publishing nightly builds: 1. Adopters don't have a fixed URL to refer to a specific build. 2. The checksums reported for the downloads do not match the downloaded artifact. This is due to the fact that the download server caches checksums and does not expect published files to change after being published. The checksum mismatch can be a big problem for adopters as it gets in a way of proper operation of automatic download processes in build systems, etc. I haven't seen such a webmaster's statement yet. Can you point me to that? What I've seen so far is the position of other projects towards their nightly build. They state that there is no guarantee on the timeline a nigthly build is available (can be overriden any time). That is also stated this way in the retention policy of Graphiti in the project portal metadata. In general I think it is a bad idea to make one's build dependent on the nightly build of another project. Instead I would always try to point to some kind of published build. We already offer a RC1 build in our milestones update site (http://download.eclipse.org/graphiti/updates/milestones) which you could use to solve the current issue. In future, I would like you to simply ask us (forum, bugzilla, mail) to make a milestone build you could consume beforehand. Michael > I haven't seen such a webmaster's statement yet. Can you point me to that? Don't know if there is a better writeup (and webmaster is copied, so he can chime in), but this should give you some background: https://bugs.eclipse.org/bugs/show_bug.cgi?id=334323#c2 > What I've seen so far is the position of other projects towards their nightly > build. They state that there is no guarantee on the timeline a nigthly build > is available (can be overriden any time). That is also stated this way in the > retention policy of Graphiti in the project portal metadata. Note that the issue is not how long nightly builds are available for (that's a separate discussion), but rather that the same download file name is overwritten nightly. This strategy clashes with download server's checksums service design. > In general I think it is a bad idea to make one's build dependent on the > nightly build of another project. Instead I would always try to point to > some kind of published build. Right. Relying on nightly builds is not ideal. The problem if what to do when the last milestone build doesn't have a major bug fix that you need. Other projects address this by publishing weekly declared builds. > We already offer a RC1 build in our milestones update site Update sites are great, but they aren't viable in all situations. We need an archived repo. The download page does not list RC1: http://www.eclipse.org/graphiti/download.php Ok, I understand that issue and will have a look into that nightly build ZIP download after Indigo is out. To solve your issue for now you can use our ZIP download of RC1 (it's been made available together with the update site, but not yet linked on our downloads page since it's not yet public). Here's the link: http://www.eclipse.org/downloads/download.php?file=/graphiti/archives/milestones/org.eclipse.graphiti.site_0.8.0RC1.201105161053.zip Sorry, I forgot that you use the zipper download. As I said: just drop us a note in case you'll need a newer milestone version and we can create one for you. Michael Thanks for the RC1 zip URL. We were able to use it. I changed the Graphiti nightly build so that it renames the created ZIP file to contain the current build-id and updated the download link in a way that it always uses the current version (done via PHP sript). That should solve the issue regarding identical download locations for the ZIP file. Please let me know in case it doesn't solve your issue. Michael Marked as part of Juno Bookkeeping: Set target release Part of Graphiti 0.9.0 (Eclipse Juno) |