Really, I just changed the one line in my target file and checked it in for all my builds. I love Tycho for that :) ________________________________________ From: cross-project-issues-dev-boun...@eclipse.org [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko [i...@ifedorenko.com] Sent: Thursday, June 19, 2014 10:29 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete
It will take me couple of hours to switch all my CI jobs from releases/luna to releases/staging and make sure they still work, and another couple of hours to switch them back to releases/luna next week. Not a huge amount of time, but I'd prefer not to have to spend it. If people are passionate about "release" event, lets publish all M and RC builds to milestones/<celestial-object> and populate releases/<celestial-object> only after the release has been declared. -- Regards, Igor On 2014-06-19, 10:02, Doug Schaefer wrote: > 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: cross-project-issues-dev-boun...@eclipse.org > [cross-project-issues-dev-boun...@eclipse.org] on behalf of Igor Fedorenko > [i...@ifedorenko.com] > Sent: Thursday, June 19, 2014 9:28 AM > To: cross-project-issues-dev@eclipse.org > 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 <i...@ifedorenko.com> >> To: cross-project-issues-dev@eclipse.org, >> Date: 06/19/2014 07:55 AM >> Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete >> Sent by: cross-project-issues-dev-boun...@eclipse.org >> ------------------------------------------------------------------------ >> >> >> >> 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 >> > cross-project-issues-dev@eclipse.org >> > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev