Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Shorter release cycles (cont...)


On 2015-05-19, 8:38 AM, "Max Rydahl Andersen" <manderse@xxxxxxxxxx> wrote:

>
>>>> As a quick summary, the suggestion was to release minor releases
>>>> more
>>>> often. I originally proposed 6 months, David then came back with 3
>>>> which
>>>> we are currently debating. Also thrown in by John is the concept of
>>>> one of
>>>> those releases being an LTS release likely once a year.
>>>
>>> Can you tell me how these are any different from just adding more SR
>>> releases and allow
>>> more than 2 SR's if there are interest for it ?
>>
>> Doing minor releases in Service Releases as we do now is confusing to
>> our
>> users and adopters. Service Releases should be only bug fixes.
>
>If we did that we would stagnate even further (at least from perspective
>of being an IDE, not only a platform).
>I think that is a bad thing.
>
>I believe we should be able to include controlled and managed feature
>additions. I believe all IDE's
>does that these days.
>
>i.e. like I believe egit have done in past - and that I believe CDT
>plans to do for things like
>launchBar.

Yes, the proposal is that there are no more synchronized service releases.
Every release, is a minor release, every three months. June to Sept and
then keep on that three month cadence. Or move it around a bit so one of
the releases doesn’t end up in the December holiday season.

>
>> My original e-mail on this suggestion also talked about the problem
>> with
>> the current SR timing.
>>
>> Also Ian Bull has suggested we get rid of synchronized service
>> releases
>> and just co-ordinate these minor releases. Projects would be free to
>> release service releases on their own time frames.
>
>I could not really care less about how often projects releases outside
>the release train ;)
>
>The importance is wether these releases are included and made available
>from the release train
>updatesite in a way that makes it possible for users AND consumers
>participating in the release
>train to actually work with them.

I have been told that projects can do service releases in their update
sites and that those would get picked up on a Check for Updates if things
are set up correctly. Whether that’s true or not, we need to confirm.

>
>>> (This is what I would actually like to see - SR's that tries to be as
>>> API compatible as possible,
>>> can get bug fixes but also don't exclude option of adding new
>>> features
>>> if it does not break API)
>>
>> I think that’s what we’re talking about. It’s just not a service
>> release
>> any more. It’s real minor releases, which by definition have to
>> maintain
>> API compatibility. We just need to figure out the window for major
>> releases, ones that can break compatibility.
>
>Well, for me the simple option is to do these at SR releases timeframe.
>But as I think is the case today - if you add something that breaks
>compatibility
>in the release train you need to provide due warnings and the PMC can
>decide to
>reject if it too much problems.

I think we need to be more formal than that. Allowing projects to do major
releases at any time affects the whole ecosystem. We need to manage that
as a planning council, for the whole train.

>
>/max
>>
>>>
>>> /max
>>>
>>>> We didn¹t discuss major releases but we can do that now but it
>>>> would
>>>> make
>>>> sense that we only allow major releases on the LTS release. Though
>>>> that
>>>> would be counter intuitive since an LTS release should be high
>>>> quality
>>>> that a major release might not give you right away. But we do
>>>> currently
>>>> have that rule where you can release minor releases on an SR and
>>>> only
>>>> major releases in June.
>>>>
>>>> Anyway, that¹s the plan. We need to think of all the unintended
>>>> consequences of all this before making an official proposal.
>>>>
>>>> Doug.
>>>>
>>>> On 2015-05-13, 8:21 AM, "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> On 13 May 2015, at 13:52, David M Williams wrote:
>>>>>
>>>>>> Welcome Max.
>>>>>>
>>>>>> I'd say we don't have a proposal yet, just an idea that we will
>>>>>> develop a
>>>>>> proposal. I'd suggest catching up with the last meeting minutes at
>>>>>> https://wiki.eclipse.org/Planning_Council/
>>>>>> ... May 6 has the most written down ideas.
>>>>>
>>>>> Thanks! I'll read up on it and come back after the bank holidays
>>>>> here
>>>>> -
>>>>> so Monday ;)
>>>>>
>>>>>> Other Planning Council members, Red Hat became a Strategic Member
>>>>>> of
>>>>>> Eclipse Foundation earlier this month, and Max will be their
>>>>>> representative to the Planning Council.
>>>>>
>>>>> I was actually looking at sending a delegate, but then this topic
>>>>> about
>>>>> changing release cycles came up so I stepped in for now.
>>>>>
>>>>> Thanks,
>>>>> /max
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From:   "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
>>>>>> To:     "Eclipse Planning Council private list"
>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx>,
>>>>>> Date:   05/13/2015 04:13 AM
>>>>>> Subject:        Re: [eclipse.org-planning-council] Shorter release
>>>>>> cycles
>>>>>> (cont...)
>>>>>> Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm joining the planning council and trying to catch up on the
>>>>>> discussion.
>>>>>>
>>>>>> What is the actual proposal ?
>>>>>>
>>>>>> Quarter releases with allowed API breakage sounds like something
>>>>>> that
>>>>>> would
>>>>>> completely destroy our ability to provide compatible versions of
>>>>>> our
>>>>>> plugins
>>>>>> and a killer of an actual working IDE in the community.
>>>>>>
>>>>>> But I assume that is not the actual proposal :)
>>>>>>
>>>>>> Can anyone point me to details of the current proposal ?
>>>>>>
>>>>>> /max
>>>>>>
>>>>>>> Well, the realities outside the Eclipse project are very
>>>>>>> different.
>>>>>>> I
>>>>>>> don¹t report to the Tools PMC or the CDT project lead, I report
>>>>>>> to
>>>>>>> a
>>>>>>> manager at QNX and I get my marching orders from him. Good only
>>>>>>> comes
>>>>>>> when my manager allows me to work for the interests of the
>>>>>>> community
>>>>>>> as well as our company.
>>>>>>>
>>>>>>> There are a lot of committers that don¹t have such kind bosses
>>>>>>> and
>>>>>>> lots come and go like the wind as their real bosses direct their
>>>>>>> work.
>>>>>>> But they contribute where they can and we appreciate what they do
>>>>>>> (for
>>>>>>> the most part) and we¹re better off than if we had turned them
>>>>>>> away.
>>>>>>>
>>>>>>> Anyway, that¹s all beside the point. We all agree that projects
>>>>>>> need
>>>>>>> good leaders that can influence their communities to work
>>>>>>> together.
>>>>>>> The projects I know about have that so I¹m not too worried about
>>>>>>> projects doing the right thing as we open up to the idea of
>>>>>>> quarterly
>>>>>>> releases. Unless there are a lot that don¹tŠ
>>>>>>>
>>>>>>> Doug
>>>>>>>
>>>>>>> From: Daniel Megert
>>>>>>> <daniel_megert@xxxxxxxxxx<mailto:daniel_megert@xxxxxxxxxx>>
>>>>>>> Reply-To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Date: Tuesday, May 12, 2015 at 5:08 PM
>>>>>>> To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Subject: Re: [eclipse.org-planning-council] Shorter release
>>>>>>> cycles
>>>>>>> (cont...)
>>>>>>>
>>>>>>>> On a diverse project, there are many bosses and they don¹t
>>>>>>>> report
>>>>>>>> to each other.
>>>>>>> Every project has a lead and a PMC. They must work together. If
>>>>>>> not,
>>>>>>> something is broken and needs to be fixed or escalated.
>>>>>>>
>>>>>>>> We just need to make sure the projects have strong leadership to
>>>>>>>> pull
>>>>>>>> it all together. I just wanted to add the data to the mix.
>>>>>>> Definitely. The prime directive for the projects (leadership)
>>>>>>> must
>>>>>>> be
>>>>>>> to deliver the best value they can provide to the community. The
>>>>>>> products/companies can then decide which releases to adopt. This
>>>>>>> is
>>>>>>> nothing new. For example we at IBM don't consume every
>>>>>>> release/SR.
>>>>>>> We
>>>>>>> have clearly defined schedules and rely on the open source
>>>>>>> deliverables. In order to make that work it is essential to have
>>>>>>> public release plans where projects indicate whether they
>>>>>>> participate
>>>>>>> in a release with new features or just bug fixes.
>>>>>>>
>>>>>>> Dani
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From:        Doug Schaefer
>>>>>>> <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>>
>>>>>>> To:        Eclipse Planning Council private list
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Date:        06.05.2015 20:29
>>>>>>> Subject:        Re: [eclipse.org-planning-council] Shorter
>>>>>>> release
>>>>>>> cycles (cont...)
>>>>>>> Sent by:
>>>>>>> eclipse.org-planning-council-bounces@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx>
>>>>>>> ________________________________
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, but my scenario was more driven by a committer team that
>>>>>>> didn¹t
>>>>>>> work as a unit. On a diverse project, there are many bosses and
>>>>>>> they
>>>>>>> don¹t report to each other. The train helped me bring the
>>>>>>> different
>>>>>>> factions together and helped us work as a unit. And ironically
>>>>>>> enough,
>>>>>>> it was because the releases were yearly and people didn¹t want
>>>>>>> to
>>>>>>> miss it. I kinda loose that hammer if we release too often. You
>>>>>>> may
>>>>>>> end up with committers taking a release off knowing they can jump
>>>>>>> back
>>>>>>> on for the next release in three months. It¹s a strain on the
>>>>>>> rest
>>>>>>> of the team.
>>>>>>>
>>>>>>> It something we can over come, and sometimes face anyway. We just
>>>>>>> need
>>>>>>> to make sure the projects have strong leadership to pull it all
>>>>>>> together. I just wanted to add the data to the mix.
>>>>>>>
>>>>>>> Doug.
>>>>>>>
>>>>>>> From: Ian Bull
>>>>>>> <irbull@xxxxxxxxxxxxxxxxx<mailto:irbull@xxxxxxxxxxxxxxxxx>>
>>>>>>> Reply-To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Date: Wednesday, May 6, 2015 at 2:19 PM
>>>>>>> To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Subject: Re: [eclipse.org-planning-council] Shorter release
>>>>>>> cycles
>>>>>>> (cont...)
>>>>>>>
>>>>>>> We may want to require projects that wish to release on the train
>>>>>>> to
>>>>>>> publicize their release schedule, and give an appropriate
>>>>>>> heads-up
>>>>>>> for
>>>>>>> any changes to the schedule. This may help with the scenario Doug
>>>>>>> just
>>>>>>> described, but also help when a component has a lot of consumers
>>>>>>> on
>>>>>>> the train.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ian
>>>>>>>
>>>>>>> On Wed, May 6, 2015 at 11:00 AM, Doug Schaefer
>>>>>>> <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>> wrote:
>>>>>>> Indeed a great discussion and again Thank You all for
>>>>>>> contributing
>>>>>>> and
>>>>>>> being open to the idea. I feel something great coming out of it.
>>>>>>> :)
>>>>>>>
>>>>>>> First for Ian¹s question, yes, one repo at a fixed URL. It¹s a
>>>>>>> requirement I have of my customers to be able to update from
>>>>>>> release
>>>>>>> to release. Our schedule is somewhat random and driven by other
>>>>>>> forces
>>>>>>> so they don¹t really know which Eclipse Platform release their
>>>>>>> getting unless they look hard at it. They¹d be pretty confused
>>>>>>> if
>>>>>>> they could upgrade to some but not others.
>>>>>>>
>>>>>>> I also wanted to add a bit of history that not many people know
>>>>>>> about
>>>>>>> other than long time CDT committers that were around at the time
>>>>>>> or
>>>>>>> heard my old grampa stories over CDT Summit beersŠ
>>>>>>>
>>>>>>> Before CDT joined the train, our release strategy was a mess. And
>>>>>>> it
>>>>>>> was really the diversity of our project that caused it. We had
>>>>>>> two
>>>>>>> major players, I worked for one and I now work for the other
>>>>>>> (hint,
>>>>>>> hint). One of them had a product based on CDT and that product
>>>>>>> delivery schedule was driven by the platform it supported. The
>>>>>>> other
>>>>>>> was trying to release in sync with the Eclipse platform so it
>>>>>>> could
>>>>>>> feed into the product stack that that company was building on
>>>>>>> top.
>>>>>>>
>>>>>>> The problem crept up with the two schedules didn¹t match. What
>>>>>>> ended
>>>>>>> up happening was that CDT released every time one of these two
>>>>>>> stacks
>>>>>>> needed a release. Unfortunately, the committers remained focused
>>>>>>> on
>>>>>>> their product release and ended up not helping the other out when
>>>>>>> it
>>>>>>> was time for them to release. In fact, on one famous occasion,
>>>>>>> the
>>>>>>> one
>>>>>>> who had a few months before their release added a new feature two
>>>>>>> weeks before the other was going to have their release. Luckily
>>>>>>> we
>>>>>>> had
>>>>>>> great leaders back then and the commit was reverted.
>>>>>>>
>>>>>>> It was a complete mess and as we started to grow committers from
>>>>>>> different ISVs, we started to ask, do we release every time one
>>>>>>> of
>>>>>>> them needed a release. That would have been complete chaos. So
>>>>>>> when
>>>>>>> the idea of the train came along I used the opportunity to
>>>>>>> standardize
>>>>>>> our releases and there was really little fuss because everyone
>>>>>>> knew
>>>>>>> that was the right thing to do and the answer was handed to us on
>>>>>>> a
>>>>>>> silver platter.
>>>>>>>
>>>>>>> So while the idea of 3 month cycles is a great advance forward, I
>>>>>>> do
>>>>>>> fear the unintended consequences. If projects aren¹t releasing
>>>>>>> on
>>>>>>> every train release, then they have a decision to make on which
>>>>>>> releases to release on. And what drives that decision? The old
>>>>>>> train
>>>>>>> gave us an automatic choice that we didn¹t have to think or fuss
>>>>>>> about. Sometimes that¹s a good thing.
>>>>>>>
>>>>>>> Doug.
>>>>>>>
>>>>>>> From: Ian Bull
>>>>>>> <irbull@xxxxxxxxxxxxxxxxx<mailto:irbull@xxxxxxxxxxxxxxxxx>>
>>>>>>> Reply-To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Date: Wednesday, May 6, 2015 at 1:36 PM
>>>>>>> To: Eclipse Planning Council
>>>>>>> <eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>>
>>>>>>> Subject: [eclipse.org-planning-council] Shorter release cycles
>>>>>>> (cont...)
>>>>>>>
>>>>>>> Great discussion today!
>>>>>>>
>>>>>>> I really like the direction we are headed, and the idea of a
>>>>>>> release
>>>>>>> once per season would make us much more agile.
>>>>>>>
>>>>>>> One technical thing we need to consider is how we will structure
>>>>>>> the
>>>>>>> repository. Currently we create a new composite repository every
>>>>>>> each
>>>>>>> (for the June release) and add the SR1 and SR2 when they become
>>>>>>> available. In the next year, we wipe the slate clean and start
>>>>>>> again
>>>>>>> with a fresh repository.
>>>>>>>
>>>>>>> If we are moving away from a Release + SR1 + SR2 and moving
>>>>>>> towards
>>>>>>> a
>>>>>>> rolling release, then I don't think we should clear the
>>>>>>> repository
>>>>>>> each year. This will make year-to-year updates impossible.
>>>>>>>
>>>>>>> One suggestion is to create a single composite repository, and
>>>>>>> store
>>>>>>> the latest N releases (N=4?). When N+1 is released we then drop
>>>>>>> the
>>>>>>> oldest release from list of children (of course we could maintain
>>>>>>> the
>>>>>>> update site forever at a permanent URL -- but that would be part
>>>>>>> of
>>>>>>> our retention strategy which we have not yet discussed).
>>>>>>>
>>>>>>> Thoughts? And thanks again everyone!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ian
>>>>>>>
>>>>>>> --
>>>>>>> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
>>>>>>> http://eclipsesource.com<http://eclipsesource.com/> |
>>>>>>> http://twitter.com/eclipsesource
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> eclipse.org-planning-council mailing list
>>>>>>> eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>
>>>>>>> 
>>>>>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-counci
>>>>>>>l
>>>>>>>
>>>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>>>> internal
>>>>>>> to the Eclipse Foundation.  To be permanently removed from this
>>>>>>> list,
>>>>>>> you must contact emo@xxxxxxxxxxx<mailto:emo@xxxxxxxxxxx> to
>>>>>>> request
>>>>>>> removal.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
>>>>>>> http://eclipsesource.com<http://eclipsesource.com/> |
>>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>>http://twitter.com/eclipsesource_____________________________________
>>>>>>__
>>>>>> __
>>>>>> ______
>>>>>>
>>>>>>> eclipse.org-planning-council mailing list
>>>>>>> eclipse.org-planning-council@xxxxxxxxxxx<
>>>>>> mailto:eclipse.org-planning-council@xxxxxxxxxxx>
>>>>>>> 
>>>>>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-counci
>>>>>>>l
>>>>>>>
>>>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>>>> internal
>>>>>>> to the Eclipse Foundation.  To be permanently removed from this
>>>>>>> list,
>>>>>>> you must contact emo@xxxxxxxxxxx<mailto:emo@xxxxxxxxxxx> to
>>>>>>> request
>>>>>>> removal.
>>>>>>> _______________________________________________
>>>>>>> eclipse.org-planning-council mailing list
>>>>>>> eclipse.org-planning-council@xxxxxxxxxxx
>>>>>>> 
>>>>>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-counci
>>>>>>>l
>>>>>>>
>>>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>>>> internal
>>>>>>> to the Eclipse Foundation.  To be permanently removed from this
>>>>>>> list,
>>>>>>> you must contact emo@xxxxxxxxxxx to request removal.
>>>>>>
>>>>>>
>>>>>> /max
>>>>>> http://about.me/maxandersen
>>>>>> _______________________________________________
>>>>>> eclipse.org-planning-council mailing list
>>>>>> eclipse.org-planning-council@xxxxxxxxxxx
>>>>>> 
>>>>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>>>>
>>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>>> internal
>>>>>> to
>>>>>> the Eclipse Foundation.  To be permanently removed from this list,
>>>>>> you
>>>>>> must contact emo@xxxxxxxxxxx to request removal.
>>>>>>
>>>>>> _______________________________________________
>>>>>> eclipse.org-planning-council mailing list
>>>>>> eclipse.org-planning-council@xxxxxxxxxxx
>>>>>> 
>>>>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>>>>
>>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>>> internal
>>>>>> to the Eclipse Foundation.  To be permanently removed from this
>>>>>> list,
>>>>>> you must contact emo@xxxxxxxxxxx to request removal.
>>>>>
>>>>>
>>>>> /max
>>>>> http://about.me/maxandersen
>>>>> _______________________________________________
>>>>> eclipse.org-planning-council mailing list
>>>>> eclipse.org-planning-council@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>>>
>>>>> IMPORTANT: Membership in this list is generated by processes
>>>>> internal
>>>>> to
>>>>> the Eclipse Foundation.  To be permanently removed from this list,
>>>>> you
>>>>> must contact emo@xxxxxxxxxxx to request removal.
>>>>
>>>> _______________________________________________
>>>> eclipse.org-planning-council mailing list
>>>> eclipse.org-planning-council@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>>
>>>> IMPORTANT: Membership in this list is generated by processes
>>>> internal
>>>> to the Eclipse Foundation.  To be permanently removed from this
>>>> list,
>>>> you must contact emo@xxxxxxxxxxx to request removal.
>>>
>>>
>>> /max
>>> http://about.me/maxandersen
>>> _______________________________________________
>>> eclipse.org-planning-council mailing list
>>> eclipse.org-planning-council@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>
>>> IMPORTANT: Membership in this list is generated by processes internal
>>> to
>>> the Eclipse Foundation.  To be permanently removed from this list,
>>> you
>>> must contact emo@xxxxxxxxxxx to request removal.
>>
>> _______________________________________________
>> eclipse.org-planning-council mailing list
>> eclipse.org-planning-council@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>
>> IMPORTANT: Membership in this list is generated by processes internal
>> to the Eclipse Foundation.  To be permanently removed from this list,
>> you must contact emo@xxxxxxxxxxx to request removal.
>
>
>/max
>http://about.me/maxandersen
>_______________________________________________
>eclipse.org-planning-council mailing list
>eclipse.org-planning-council@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
>IMPORTANT: Membership in this list is generated by processes internal to
>the Eclipse Foundation.  To be permanently removed from this list, you
>must contact emo@xxxxxxxxxxx to request removal.


Back to the top