How often do the Eclipse packages get build and tested and what appears on the Eclipse download page?
On 13-07-03 12:02 PM, "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com> wrote: >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 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
