Community
Participate
Working Groups
From mailing list, the 1.0.0 version of javax.persistence is old enough that there is no reason to leave in active builds ... with the better alternative that people have been using from EclipseLink. ./staging/aggregate/plugins/javax.persistence_2.1.0.v201201251030.jar ./staging/aggregate/plugins/javax.persistence_2.0.4.v201112161009.jar ./maintenance/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./galileo/200909241140/aggregate/plugins/javax.persistence_1.99.0.v200906021518.jar ./galileo/201002260900/aggregate/plugins/javax.persistence_1.99.0.v200906021518.jar ./helios/201102250900/aggregate/plugins/javax.persistence_2.0.1.v201006031150.jar ./helios/201009240900/aggregate/plugins/javax.persistence_2.0.1.v201006031150.jar ./helios/201006230900/aggregate/plugins/javax.persistence_2.0.1.v201006031150.jar ./juno/201108190900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./juno/201111110900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./juno/201112160900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./juno/201109300900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./indigo/201106220900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar ./indigo/201109230900/aggregate/plugins/javax.persistence_2.0.3.v201010191057.jar
Any thoughts on how we guarantee no one else is using this prior to removing. (We use, but do not distribute a version for our backwards compatibility testing and we need to make sure no one else is doing that too.)
(In reply to comment #1) > Any thoughts on how we guarantee no one else is using this prior to removing. > (We use, but do not distribute a version for our backwards compatibility > testing and we need to make sure no one else is doing that too.) Well, remember, it will be always there (in "old" Orbit repos and builds) and can be fetched from there in a number of ways. Not being in the active build would mean it would be (slightly) harder to "fix" something in it, such as if it was discovered the manifest.mf file was missing an export or something ... but, that seems unlikely, after so many years of use with no bug reports. And, not having in active builds will make it obvious to the uninitiated not to use that one moving forward. Make sense?
makes sense to me.
What is involved in removing the library from the recent Orbit builds?
Remember, we won't remove it from "recent builds" but for _active_ builds ... so will drop out of future builds. The following mechanics are listed in http://wiki.eclipse.org/Orbit/Promotion%2C_Release%2C_and_Retention_Policies Mechanics: When a bundle is to be removed from active builds, the following steps should be followed: have a bugzilla entry that mentions what is being removed, when, and ideally states the "last good R-build" that contains the old version. remove bundle entry from the feature.xml file (and release it for a build, at some point, when ready) remove the bundle entry from the bundles.map file. leave the entry in the IP Log file, but add a note that says something similar to "No longer in active builds since this version is no longer current. If required, please get from an older R-build repository, CVS, or open a bugzilla if needs to be re-instantiated in active builds". ideally should update the original "Orbit CQ" to simply mention that version is no longer actively built by Orbit. This is just to help cross-reference information, in case someone is looking for that bundle. Orbit does, technically, still "distributes" it, since it is available in old repositories ... it is just an informational message.
