Removing Photon.

[Mario Torre]

On the other hand, if we want to drop support for Photon and bump the
minimum version, we should do it at the major release mark. If we miss
the 8 timeframe, the next useful cycle is going to be 9 (because we
really don't want to break stuff in minor releases).

So if this is something we really want to do because the benefits
outweigh the cost, I suggest the following:

1. Do it now rather than later :)
2. In the future, plan it ahead so we give time for downstream to prepare

Cheers,
Mario


On Fri, Feb 21, 2020 at 3:57 PM Jie Kang <jkang at redhat.com> wrote:
>
> On Fri, Feb 21, 2020 at 9:51 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >
> > Hi Jie,
> >
> > I think the problem/benefit is that if a target platform is removed, we will eventually start depending on newer functionality, and it will quickly become harder to build with the removed platform. So, if we want to continue to support running with Photon, then Photon should remain amongst the target platforms. Arguably, we may want to build on photon as well, at least on one platform, just to discover if we start depending on too recent APIs, as happened recently.
>
> Ah you're right; I missed this completely, that's my bad.
>
>
> Regards,
>
> >
> > /M
> >
> > On Fri, Feb 21, 2020 at 2:30 PM Jie Kang <jkang at redhat.com> wrote:
> >>
> >> On Fri, Feb 21, 2020 at 4:11 AM Mario Torre <neugens at redhat.com> wrote:
> >> >
> >> > On Thu, Feb 20, 2020 at 8:12 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >> > >
> >> > > Reasons for:
> >> > > * Being able to use more recent additions and APIs.
> >> > > * Less platforms to test against.
> >> > >
> >> > > Reasons against:
> >> > > * Convenience in not having to upgrade Eclipse for people installing into older Eclipses.
> >> > > I will not list convenience in not having to seek third-party approvals to be able to release RCP builds on old versions of the platform, since you'd normally would want the latest fixes in your release versions.
> >> > >
> >> > > That said, I'm not feeling strongly about this. If you have a strong reason for keeping it around, then we can.
> >> >
> >> > It makes downstream packaging more difficult when the baseline is a
> >> > moving target, this is why I asked if there are strong reason. If
> >> > there's API we need and there are no alternatives (or very less
> >> > convenient ones), or if there is a critical fix that affects
> >> > functionality but that makes it an incompatible change, this is a
> >> > valid reason of course.
> >> >
> >> > Since this only affect the minimum version required to build and use
> >> > JMC, and not the default one used upstream, I don't think we should
> >> > move unless the afore requirement is met.
> >> >
> >> > That said, I always maintain that upstream should not necessarily care
> >> > about downstreams or make decision solely based on downstream
> >> > reasoning, but being good citizens is nice if we can help.
> >>
> >> Hi Marcus, Mario,
> >>
> >> I think the content added/removed for building with a target platform
> >> is so minimal, so self-contained and so trivial that a removal is not
> >> a problem.
> >>
> >>
> >> Regards,
> >>
> >> >
> >> > Cheers,
> >> > Mario
> >> >
> >> > --
> >> > Mario Torre
> >> > Associate Manager, Software Engineering
> >> > Red Hat GmbH <https://www.redhat.com>
> >> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >> >
> >>
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898