Re: [cross-project-issues-dev] 6 month release cycle

[Doug Schaefer <dschaefer@xxxxxxx>]

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.komissarchik@xxxxxxxxxx> 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@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev