Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Talk:Orbit/Promotion, Release, and Retention Policies
Comments from Martin Oberhuber:
Do we really need multiple different qualified versions in the bundles area? By definition, these have the same content in terms of class files but slightly different meta-info, "markup" or licensing words. I would expect that such "markup" can only get better over time and can't see any reason why anybody would want a "previous-qualified" version. Especially, I cannot see how clients would ever reliably select a particular one from multiple different qualified versions (except referencing exactly one but that's also unreliable since it may be gone at some time).
The only compelling reason for keeping old "qualified" versions of bundles would be to be able and reproduce old builds exactly as they were. But for this, just keeping 3 qualified versions is not sufficient -- rather than that, clients would need to advertise what they put into an official release. It might be better to plan that clients who need to reproduce an old build should do that by running the Orbit build scripts out of CVS themselves rather than downloading some pre-built bundle. It might be a good idea anyways to make the Orbit build scripts such that they can run on any client's computer.
Also, if I'm not mistaken one of the prime reasons for Orbit was to ensure that all clients of a given library version use exactly the same binary. This means that at release time there can be only one qualified version - "the" version for everyone. No point in allowing anyone use any other qualified version than what's the official Orbit version.
My EUR 0.02
Comments from Kim Moir
I also don't think that there should be multiple versions of "qualified" bundles in the bundles directory. It will cause confusion with with people using multiple qualified versions. A requirement for us that the bundles that we consumed for milestone builds during a release cycle should remain available during that release cycle. After the release, we don't care, we won't be reproducing milestone builds. Perhaps before the official Europa release at the end of June, there should be a bundlesEuropa, from which all teams should consume their bundles so everyone is on the same page.
Replies from David
Thanks for the comments. The only reason I mentioned leaving multiple qualified versions was so as to not suddenly break any consumers builds. I assumed that some folks would have to specify the qualifier to include in their build. But, re-reading bug 171869 I think perhaps I was wrong? Is it true that using a GET in a map file, would get the mostly recent qualified version of a specified jar? If that's the case, then yes, I agree, no need to retain any. And, that makes bug 171869 all the better, for those that use map files. (but, honestly, don't see how that would work with the ANT task). Certainly for any overall zipped-up for update-site deliveries (if any) we'd only include the most recent. So, as long as there is no danger of suddenly breaking a consumers build, I'm set. If there is still that danger, then I'd suggest we could specify the policy to something like "retained for four weeks" (or something) ... just to give folks some window to update their builds. But, I agree, the goal is to end up with just one that everyone uses, and, as I mentioned, once in the bundles area, should be rare to ever have to change after that (I hope!)
Another comment from Kim Moir
Yes, when you deleted the old builds yesterday it broke a test build I was running :-). I would just suggest that everyone use the milestones builds at all times unless they are testing bundles that they themselves have submitted to Orbit.