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

[Doug Schaefer <dschaefer@xxxxxxx>]

I wonder, for those companies that want stability, should they focus on
the LTS program where old releases are maintained for long periods of time.

I'm of the opinion that the entire stack needs new feature development, at
least on the IDE side. We are falling behind the competition and my
thinking and hope is that releasing more often would help energize the
community.

On 13-07-03 6:10 AM, "Ed Merks" <ed.merks@xxxxxxxxx> wrote:

>Releasing more often sounds like a good thing in principle and of course
>projects are free to do so as they wish.  One major concern I'd have
>about the release train itself releasing more often is the long ramp
>down cycle appearing twice as often per year.   Of course the M/RC phase
>would need to be shorted, but then the question is, why is it currently
>so long?  I expect the answer if to provide quality and stability, so
>would that inevitably suffer as a result? That would be a bad thing...
>
>Another question we must ask is what's best for the consumers/adopters?
>On the one hand, I imagine for projects with very active feature
>development, many of their consumers do want the latest and greatest as
>often as possible.  On the other hand, I also imagine that a great many
>commercial adopters see quality and stability as their primary criteria
>for adoption and hence see more value in SR1 and SR2 releases of a
>stable base that's focused primarily on quality improvements compared to
>all the new feature development, which is almost inevitably associated
>with lower quality.
>
>
>
>On 03/07/2013 11:44 AM, Krzysztof Daniel wrote:
>> For Eclipse as a product it is definitely good to have releases more
>> often. It will lower the entry barrier (patches could find a way in the
>> release in less then a year), and will attract new contributors.
>>
>> BUT at the same time there is Eclipse as a platform, with API
>> compatibility, with service releases and specific change management
>> policies, which is totally different from the Eclipse-As-A-Product.
>>
>> So, maybe the key point is that there is a need for two lines:
>> - release train, kept as it is currently
>> - rolling release - it is a product. rather for users then for
>> developers. New API and features can be withdrawn.
>>
>>
>>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev