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.
Thoughts? Am 03.07.2013 09:22, schrieb Matthias Sohn: > On Wed, Jul 3, 2013 at 8:57 AM, Dennis Hübner <dennis.hueb...@itemis.de > <mailto:dennis.hueb...@itemis.de>> 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. > > Finally a good idea! > 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 > version. > > -- > Matthias > > > _______________________________________________ > 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
