Sounds reasonable to me. Sounds about like what I do! I think the "key" is what URL you publish to "the public". If you publish only one, say http://download.eclipse.org/modeling/emf/cdo/ then as long as that one remains "invisible" until release day, you are good to go. That is, the latest "released" contents there remain invisible ... there could always be other releases, etc., visible there. The question is, if someone "checks for updates" will they get your release "early"? Which then might not "match" what ever else they have ... for better or for worse.
If you find your self having the "released bits" visible there, and you are are talking about making another subdirectory with same contents that remains invisible, then nothing is really being gained ... and part of what you say almost sounds like that ... but, hard for me to tell. Hope this answer helps a little. From: Eike Stepper <step...@esc-net.de> To: cross-project-issues-dev@eclipse.org, Date: 06/20/2012 10:53 PM Subject: Re: [cross-project-issues-dev] On when to update aggregation files to point to final release repos Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David, List, This is a good opportunity for me to ask whether our approach is ok, too. In the past our RC4 drops were the result of R-builds, i.e., after the promotion the drop folder on download.e.o had the name "R20nn...". By default our promotion service leaves all S-build and R-build drops invisible, i.e., they don't appear on our downloads page and they don't end up in our composite p2 repos. The advantage is that the aggregation as well as the mirrors are well prepared for GA. Everything is properly in place for GA right after RC4. The disadvantage is that I can not present an explicit and visible RC4 drop. Therefore I'm currently working on a promotion script that automates the copy/rename process of already promoted drops. With that I want to promote a proper S-build as the visible RC4 drop and then copy it to an invisible GA drop that has R-build quality. Does that sound reasonable? Cheers /Eike ---- http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper Am 20.06.2012 16:55, schrieb David M Williams: > It depends a little. But the safest thing to do is leave RC4 in place until 6/27 (or, maybe remove 6/26, Tuesday, one > day, before release) and leave aggregator file pointing to it, RC4. > Then on 6/27, release becomes visible and aggregator file can be updated then to point to final release location. > > In my experience, some users will still be trying to access RC4 stuff even this week and next, even knowing that the > release is next Wednesday ... so, besides aggregation concerns, best not to leave your users empty handed. (and, main > release location should be "invisible" to them until 6/27. > > We always say "no rebuilds for any reason, at all, ever" after Monday 5 PM, so ... it is "ok" if the aggregator files > are broken for a day or two next week. > Of course, it would take an act of ... someone very powerful ... to do a rebuild even now so if you break aggregation > files now, I doubt anyone would notice :). > Then, its just between you and your users/adopters. > > I'm sure there's many variations on these theme others have found that works for them, but I think the above it good > blend of "safety" and "efficiency". > > HTH > > > > > From: Mark Russell <mrruss...@google.com> > To: David M Williams/Raleigh/IBM@IBMUS, > Date: 06/20/2012 10:34 AM > Subject: windowbuilder > ------------------------------------------------------------------------------------------------------------------------ > > > > currently my aggrigation file points to _http://download.eclipse.org/windowbuilder/WB/rc/4.2.0-201206121200-RC4/4.2_ > > when Should I update it to point to _http://download.eclipse.org/windowbuilder/WB/release/_R201206261200/4.2 which is my > release directory > > -- > Mark R Russell > (724) 473-3140 > Software Engineer in Test > Google Pittsburgh > > > > > _______________________________________________ > 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
