Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Proposing slight change in retention practices

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].



Back to the top