Or it means that the workload on the IP team is spread more regularly throughout the year.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Henrik Rentz-Reichert
Sent: July-03-13 3:34 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle
some more considerations:
If we accelerate the release cycle this would also put an extra burden on the Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...)
Also, in my experience I need to start this process several weeks prior to the planned release.
A frozen IP log though means that I can't integrate 3rd party contributions any more into the upcoming release.
Am 03.07.2013 09:22, schrieb Matthias Sohn:
On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner <dennis.huebner@xxxxxxxxx> wrote:
All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it’s out. Every month, there is a
repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set
schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.
I like this proposal. IMO releasing often is a good thing.
Personally I most often use an M-build of the platform mixed with a recent nightly
of those projects I am contributing to in order to experience what's coming in.
At $DAYJOB we are releasing every 2 weeks.
So far we (JGit/EGit) did a release every 3 months shipping a major release with SR0
and minor releases with SR1, SR2 and an additional one in Dec which doesn't match
a release train delivery. If we would get the chance to release more often I'd like to
participate in that, though I am not sure if we would be able to create a new release
every month so e.g. during vacation time it may happen that we would not ship a new
cross-project-issues-dev mailing list