Glad to see interest in my frequent aggregation proposal. To answer some of the questions that were raised...
1. Monthly releases sounds rather too frequent. Doesn't leave a lot of room for milestones or IP team to do their work. Projects would release at whatever pace makes sense to them, set their own schedules and leave room for IP team to do their work. Some would continue to release yearly, some would be on a six month cycle, some would release even more frequently. The aggregation stream would only accept a finished release. In fact, given enough automation, the aggregation can become continuous. Suppose that instead of the current system where projects edit stuff in Git, there is a portal where projects contribute their release. Verification runs automatically, if it fails, the contribution is rejected. No more missing about.html files! The tool can also be available on "verify only" basis for projects wishing to check their release candidates. 2. What happens if there is a dependency conflict? For instance, if GEF pushes a new release, but the contributed GMF release still depends on the old version. We would very likely need to allow multiple versions in the repository for frequent aggregation to work. Perhaps only the latest version is categorized. 3. Should the aggregated repository be verified? Yes. The primary value of the aggregated repository is that there is a version of each component that can be installed together. If we don't verify at aggregation time, we will lose that feature. However, with multiple versions being present, the verification would need to be different. Instead of verifying if everything can be installed together, it should verify if a solution exists such that at least one version of each component can be installed with everything else. 4. What about LTS and others who want more stability. Do we still need the current release train for that? Not really. Let's call what I've described the latest stream. Periodically, the latest stream can be branched to create a stable stream of a given vintage. Projects can still contribute to the stable stream, but the rules are different (stricter). On the opposite end, we could also have a dev stream, where projects can contribute their latest milestone builds, integration builds, etc. 5. What would I build against? Projects should be tracking the release plans of their dependencies and build directly against the repositories published by their dependencies. Building against any aggregation stream is risky since you never know which version you are building against and you lose ability to reproduce your build. Thanks, - Konstantin _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev