For what it's worth, I'm testing our internal product builds against releases/staging, and we're fine with that. We've probably spent more time on this thread than it does to change your target to point at it.
Doug. ________________________________________ From: [email protected] [[email protected]] on behalf of Igor Fedorenko [[email protected]] Sent: Thursday, June 19, 2014 9:28 AM To: [email protected] Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete I don't believe Tycho approach (and Maven/Nexus in general) is a good role model. I also don't think it applies to symrel process. As a symrel consumer, I know that d.e.o/releases/<celestial-object> is the place to get latest published M/RC build towards the next release and this is what I am told to use throughout yearly release cycle. Few weeks before the release, however, I need to switch to another repository to test with the final RC. This is rather surprising (and I am quite certain I'll forget about this by next May) and requires non-trivial amount of work on my part because I need to update all my build scripts and/or CI jobs to use the staging repository. If you are really concerned about "releasing" final RC to releases/<celestial-object> couple of weeks earlier, then I think we need separate stable prerelease repository URL. This is what we do for m2e, for example. All M and RC builds go to the same milestones/<version>/ repository and the final RC is promoted to releases/<version> repo when the release is declared. Personally, though, I find concerns about "releasing" early quite silly. To me "release" is purely marketing event. As a developer I write code and publish builds as they become available. One of the published builds is later declared a release, but this has little/no impact on my development workflow. -- Regards, Igor On 2014-06-19, 8:21, David M Williams wrote: > The reason we don't do that is because that would be the same as > "releasing it" ... that, and the URL ..../release/luna is "built in" to > all prior Luna milestones and candidates, so people with "auto update" > set would all start hitting 'download.eclipse.org' the moment it was > there, before there was opportunity to mirror. > > I think it's very common for many projects (such as Tycho) to be > available in a "staging" location for a period, before officially moving > to the "released" location. > > Perhaps this FAQ would help? > http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_way_to_test_with_the_staging_repository.3F > > > Thanks for suggesting ways to improve the process, though. > > > > > From: Igor Fedorenko <[email protected]> > To: [email protected], > Date: 06/19/2014 07:55 AM > Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete > Sent by: [email protected] > ------------------------------------------------------------------------ > > > > Little late to the party, but I'd like to suggest adding RC4 to Luna > composite and making this part of symrel process going forward. By > "hiding" RC4 under obscure URL we artificially limit amount of testing > it gets and make it harder for downstream projects validate their code > will still work yearly release comes live next week. > > -- > Regards, > Igor > > On 2014-06-11, 23:52, David M Williams wrote: > > http://download.eclipse.org/releases/staging/ > > > > As I am sure you all know, this is our final aggregation build for Luna, > > unless a blocking issue is found. > > > > I always like to emphasize, that, at this point, a "blocking issue" that > > would lead to a re-spin has to be more than a typical "bad problem" for > > a one project ... but more along the lines of something that "destroys > > all data in a project or workspace" or "prevents installs or updates of > > other projects from occurring" or that sort of thing. If you do find a > > bad bug that effects just your project's function, I encourage you to > > a) look for and document "work arounds" and/or b) prepare a "project > > level patch" that you could make available by the time we release, so > > users can take advantage of it immediately after they install the > > release. This is purely for stability reasons ... that is, it is often > > better to "ship" with a known bad bug, than to risk fixing one bug and > > exposing something even worse (which would be hard to find in time, > > since by then little time left for testing). And just so I don't seem > > negative ALL the time ... if you sincerely believe you found a bug that > > really would be bad for the reputation of Eclipse as a whole, or > > something, discuss with your project and PMC and other Eclipse leaders > > and if they all believe it worth mentioning here on cross-project list, > > then please do. Even if the answer is "no, no re-build", it doesn't hurt > > to keep everyone informed. > > > > Also important for you to know, this "staging" repo is NOT moved to > > .../releases/luna on Friday, like we normally do, since that is Friday > > the 13th [JUST KIDDING!]. The real reason it just stays on staging is > > that would essentially be "pre-releasing" the whole train. Instead we > > always have a "quiet week" for final preparations, final adopter testing > > and builds, etc., and then formally release it (make visible) on the > > long scheduled date of Wednesday, June 25th. > > > > I will be sending out a "what to do during quiet week" note in the next > > day or two (some version of "Kepler Final Daze > > <https://wiki.eclipse.org/Kepler/Final_Daze>" document, updated for > Luna). > > > > Let us know if questions or issues, by posting here to this > > cross-project list. > > > > And my personal thanks for those final pushes for improvements in "repo > > reports <http://build.eclipse.org/simrel/luna/reporeports/>" -- no > > missing "about" files, good improvements in unsigned bundles, and some > > improvement in making feature licenses (SUA's) current. We'll continue > > to work towards perfection for SR1 and Mars! > > > > Much thanks to you all, > > > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
