Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] 6 month release cycle

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



Back to the top