Normally I do not announce Orbit's candidate builds here, but this one is more significant than most. It may break some of your builds.
See the following orbit-dev message (and the bugs it points to) for details, but our candidate for M7 has 135 "old versions" removed. https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04474.html I would like to promote whatever the latest I-build is to an S-build "early" next week so it would be great if most of you could try out this candidate repository, http://download.eclipse.org/tools/orbit/downloads/drops/I20160421150943/repository/ and see what breaks. That is, let me know if I removed something you still need. If you can not do a build that easily in the next day or two, at least look at the "deleted" list or "included" list to confirm "by hand". Please make a comment in Bug 489949 if you need something restored. Thanks P.S. remember, for long term maintenance, etc., this "removal" does not effect any existing "R-build" repositories, just our "active builds" for Neon. From: David M Williams/Raleigh/IBM@IBMUS To: [email protected], Date: 03/21/2016 11:37 PM Subject: [cross-project-issues-dev] Notice of a change in Orbit's retention policy for "active builds" Sent by: [email protected] In the past, we Orbit committers thought we should keep "3 versions" of a package in "active builds". But long ago problems with that approach became apparent. Now is a good time to change the policy as we are making some progress on a new build system. Before we "cut over" (which I expect to formally be around the time of the Neon release) we want to have one, minimal, pristine p2 repo that was based on the old build technology. But, even if we were not doing that new build system, the new policy makes a lot more common sense. (And, to be clear, this does not change the policy of retraining "R-builds" -- as before, those builds are kept "forever".) We are changing the policy to keep only one (the latest) version in Orbit active builds -- with several known exceptions and most requested exceptions. Above all, we do not want to impact anyone in the "simultaneous release". And we have good and easy data on what is used there. The larger risk is impacting projects that are not part of the release train. Those project will need to tell us if they need something in active builds (or, they can simply get the older stuff from a previous R-builds). The written version of the policy is at https://wiki.eclipse.org/Orbit/Promotion,_Release,_and_Retention_Policies#Bundle_Retention_in_active_builds If anyone wants to see the difference between the old policy and the new, it is there in Wiki History: https://wiki.eclipse.org/index.php?title=Orbit%2FPromotion%2C_Release%2C_and_Retention_Policies&type=revision&diff=402896&oldid=371840 The one exception to what is written is we say "normally old stuff should be removed by M6" -- but, we are not making that deadline this year. We will be removing a lot of old stuff soon, so that by M7 we should be relatively clean and stable. I have opened the following bug to detail which "active" old bundles will be retained and which removed. Please comment there if you have a special case that is not obvious. Bug 489949- remove "old stuff" from active builds If any specific issues or questions, the best place to ask is in Bug 489949or the orbit-dev list. Thanks, P.S. If you haven't yet, a good time to be sure to get your Orbit bundles from the M6 delivery, so we have a more accurate picture of what is required and what is not. That M6 repository is at http://download.eclipse.org/tools/orbit/downloads/drops/S20160308060251/repository/ _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
