| Re: [eclipse.org-planning-council] Shorter release cycles (cont...) |
|
From: Ian Bull
Sent: Wednesday, May 13, 2015 5:27 PM
To: Eclipse Planning Council private list
Reply To: Eclipse Planning Council private list
Subject: Re: [eclipse.org-planning-council] Shorter release cycles (cont...)
|
So the version shown in the major increment.txt file (there is only one version shown per IU) is the SR0 version? I don’t get it. You have CDT IUs in there and I know we haven’t done a major release of anything in years.
Anyway, I think you’ve stated the point. Doing minor releases at an SR like we’re doing now is bad. People consider it to be truly an SR, not a minor release. And we do have the rule that you can only do a major release at SR0.
Photran may be violating the rule, assuming they didn’t also ship 9.0.0 at SR0 (I.e. Forgot to update the version number. Happens out there…)
Doug.
From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Wednesday, May 13, 2015 at 5:00 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Shorter release cycles (cont...)
Doug,
I know we don't version the train explicitly. But there is perceived notation of what our releases mean, as Max was alluding to. We call the fall release an SR, but really it includes over 1,000 IUs that have incremented their minor release number, and a handful that have incremented their major release number. So, to put this in a more direct way: what is the current rules around changing the versions of bundles that are included in the train?
Regarding what I attached, those are a list of IUs (and their version in SR2) that had a major version increment. For example org.eclipse.photran.core shpped version 9.0.0.201502031411 in SR2 and shipped version 8.0.0.201406102021 in SR0. If someone depends on photran.core, would they consider our February Luna release an SR, Minor, or Major update?
Cheers,Ian
On Wed, May 13, 2015 at 1:50 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Wednesday, May 13, 2015 at 3:50 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Shorter release cycles (cont...)
How do we define 'major' release for the simultaneous release? I understand our semantic version scheme for bundles, but how does that move up the stack to the train? Does the train itself increment it's major version if one of the bundles breaks API, or increments its major version?
We don’t version the simrel now other than a goofy name ;). I imagine we would keep with that. And with that, the date number probably make more sense. 16.06, 16.09, …
From Luna SR0 - SR2 there were 62 Installable Units that had a major version changes. I don't know if these IUs represent bundles that contain API, but if they do, then wouldn't that mean that SR2 was a Major Release?
Sorry, looking at your list, I don’t see any one with a major version change, e.g. 5.0.0. Lots of minor version changes, 8.7.0, but those are allowed on an SR at the moment. Ideally, only third digit increments are allowed on a SR.
From Luna SR0 - SR2 there were 1100 Installable Units that had minor version changes, presumably many of those had new API.
Doug's right, calling our Fall and Winter releases 'SRs' is lying, especially when we have strict rules about API and Eclipse has been the gold standard for API compatibility. We were doing semantic versioning before the term semantic versioning existed.
So there is really 3 parts to this whole discussion:
- Fix the name / message around our Fall and Winter releases.
- Improve the frequency at which Eclipse projects can get their bits into users hands
- Formalize what we expect regarding API and the Simultaneous Release Train
I've attached the results of my analysis (major & minor increment from SR0 to SR1). I wrote a small script to pull this data and did a few sanity checks. If you see anything wrong, please let me know. A really interesting one is the bundle org.eclipse.rcp when from 4.3.100. to 4.4.2 between SR0 and SR2.
Cheers,Ian
On Wed, May 13, 2015 at 10:51 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
On 2015-05-13, 1:33 PM, "Max Rydahl Andersen" <manderse@xxxxxxxxxx> wrote:
>On 13 May 2015, at 14:32, Doug Schaefer wrote:
>
>> Hey Max, glad you guys have joined.
>>
>> 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.
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.
>
>(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.
>
>/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-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<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-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<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-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.
_______________________________________________
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.
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
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.
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
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.