Re: [eclipse.org-planning-council] Shorter release cycles (cont...)

["Max Rydahl Andersen" <manderse@xxxxxxxxxx>]

> > > 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.

> 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.

> > (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.

/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-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.


/max
http://about.me/maxandersen