I say "practice" because our retention policy [1] is not explicit about "composites".
See bug 489967 [2] for more details but in short I propose we leave only a couple of milestones repositories in the .../eclipse/updates/4.6milestones composite and, say, 4 in the .../eclipse/updates/4.6-I-builds composite. The "raw" simple repositories would stay in place and following existing retention policy, I propose. [but am open to suggestions]. This started because I realized we have "dropped" some features and bundles from our repositories this cycle (e.g. Equinox's Aspectj weaving -- but not Equinox weaving in general) and I was thinking if someone was casually building or testing on whatever they got from .../eclipse/updates/4.6milestones they might have a big surprise once we released. [Building against a composite is a bad idea to begin with ... but ... just in case, I thought it would be the community friendly thing to do.] But, in addition, and maybe more important, doing an update from one milestone to the next, or one I-build to the next, gets longer and longer the closer we get to the end of a release or milestone because so many "sub repositories" are linked to the composite. [I have never measured it, but, seems longer, to me.] If anyone can think of some down-sides that make this proposal a bad idea, please comment in bug 489967[2]. Thanks, [1] https://wiki.eclipse.org/Eclipse_Project_Update_Sites [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=489967
_______________________________________________ equinox-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/equinox-dev
