Bugzilla – Full Text Bug Listing
| Summary: | Update site for stable builds | ||
|---|---|---|---|
| Product: | Community | Reporter: | Richard <codesamuraix> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | codesamuraix, gunnar, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 164390 | ||
| Bug Blocks: | |||
|
Description
Richard
It'd be nice if milestone builds could be obtained from an update site... I hope they really implement it. What is "a beta test version"? Do you mean milestones of each of the projects (Mx)? Do you mean release candidates (RCx)? Do you mean integration builds (I-*)? Just trying to clarify the terminology. the beta versions I meant were the milestones versions. I know I might sound technologically greedy and asking the impossible. But can make your update site be progressive? Progressive meaning it updates according your project life cycle. If you are in your milestone phase, have the update site update the milestones. If you are coming out of the milestone phase and into RC phase, update the last milestone version to the for first RC version and continue to update using later RC versions after that. If you are officially releasing, update last RC version to the official version. I honestly do not know anything about Integration versions in your project life cycle. But I think you can fill in the missing pieces. Technically everything is possible. :) As far as the Eclipse SDK is concerned there is even no difference between a milestone build and an RC build from a build type point of view. There are both so called stable builds (see http://download.eclipse.org/eclipse/downloads/build_types.html). +1 for having an update site for stable builds. Thanks for the build information. I hope you will implement this. Re comment 5 - I think you're asking for the impossible but only because you don't seem to understand the Eclipse project's lifecycles. Technically it's possible to have a single update site. But let me make one point and then ask some more questions: * Each Eclipse project is run independently. There is no centralized authority which schedules the projects to do milestones or releases concurrently. This year, ten of the projects have agreed to release simultaneously (codename: Callisto). The other 42 Eclipse projects may or may not have the same release cycle. Question 1: what if project X releases M3 on 1-Jan and project Y releases M5 on 1-Feb and then project X releases M4 on 1-Mar, but Y.M5 does not work with X.M3. So in Jan, the update site would contain ( X.M3 ) = good. In Feb, the update site would contain ( X.M3, Y.M5 ) = good. In Mar, the update site would contain ( X.M4, Y.M5 ) = bad because these two don't work together. So do you really want the latest milestone of every project? Question 1a: Don't you really want "the latest consistent version of all the projects"? That may not be "the latest milestones" because the different projects move at different speeds. Question 2: if we have milestones, release candidates (which are just miletones), and releases on the update side, then the releases would only be on the site for six weeks before the next milestone took over the top spot. For example: the Eclipse platform 3.2 Final will be released on June 28th. The Eclipse platform 3.3M1 will be released six weeks later. Thus anyone coming to the update site in August would start getting the (potentially flakey) milestone releases instead of the (usually dependable) final release. Is that the desired behavior? (In reply to comment #8) > Question 1: what if project X releases M3 on 1-Jan and project Y releases M5 on > 1-Feb and then project X releases M4 on 1-Mar, but Y.M5 does not work with > X.M3. So in Jan, the update site would contain ( X.M3 ) = good. In Feb, the > update site would contain ( X.M3, Y.M5 ) = good. In Mar, the update site would > contain ( X.M4, Y.M5 ) = bad because these two don't work together. So do you > really want the latest milestone of every project? In theory, the Eclipse Update Manager should transparently handle all such cases, i.e. not activating invalid configurations. However, this requires to keep more than the current milestone build on this update site. > Question 1a: Don't you really want "the latest consistent version of all the > projects"? That may not be "the latest milestones" because the different > projects move at different speeds. That's an interesting point, i.e. having a different update site for each release train. > Question 2: if we have milestones, release candidates (which are just > miletones), and releases on the update side, then the releases would only be on > the site for six weeks before the next milestone took over the top spot. For > example: the Eclipse platform 3.2 Final will be released on June 28th. The > Eclipse platform 3.3M1 will be released six weeks later. Thus anyone coming to > the update site in August would start getting the (potentially flakey) > milestone releases instead of the (usually dependable) final release. Is that > the desired behavior? I don't even think the stable builds should be put onto the same update site as the release builds. I think it shold be a different update site and people should be required to add it manually to their booksmarks. See bug 77143 for a versioning discussion. I would even consider marking this bug dependend on bug 77143 because this bug looks like an infrastructure request to me whereas bug 77143 discusses the implementation. ;) Re: comment 8, you are right. I did not know that your project life cycles was not centrally coordinated and independent. All I do is program in java. Eclipse is one of my tools. Your questions being up very points. No one would like version clashes and incompatibities including me. I would the first one to scream. However, it would great to have such an update site. There has to be some coordination to pull this off. Is calisto going to resolved this bug report? Can anyone answer my question? (In reply to comment #11) > Is calisto going to resolved this bug report? Richard, Callisto is a series of releases. You won't find milestone builds on the update site. (In reply to comment #13) > Richard, Callisto is a series of releases. Sorry, this sounds ambiguous. I meant to say that Callisto contains only official release builds and no milestones. OK. Thanks. (In reply to comment #14) > (In reply to comment #13) > > Richard, Callisto is a series of releases. > Sorry, this sounds ambiguous. I meant to say that Callisto contains only > official release builds and no milestones. I re-read through these comments, and if we have any hopes of implementing this, I think something like bug 164390 would need to be implemented for all the projects. I'm marking this bug as dependent on that one. *** This bug has been marked as a duplicate of bug 229969 *** |