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

Successful aggregation would trigger packages build. Different packages
should be able to build in parallel. The new repo and packages are pushed
out on the download site at the end of the monthly cycle. 

- Konstantin

-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug
Sent: Wednesday, July 03, 2013 9:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle

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 
>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 
>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.
>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.
>- Konstantin
>cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top