Re: [lsp4e-dev] Targetting Photon on master?

[Elliotte Rusty Harold <elharo@xxxxxxxxxxx>]

I'd be reluctant to abandon 4.7 this early. I still get email from
users complaining about a 4.5 minimum for my plugin.

What, specifically, is gained by requiring 4.8? Can we see a detailed
list of how this helps? What bugs are fixed in 4.8 that impact LSP4E?
What new APIs do you want to rely on?


On Wed, Dec 20, 2017 at 6:05 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
> Hi all,
>
> As you may be aware, Platform receives a lot of enhancement these days. Some
> of them are triggered by LSP4E or other projects whose requirements end up
> being implemented in Platform. That's an extremely good thing!
> However, some difficulty arises when we want LSP4E to take advantage of the
> latest improvements. For example, code lens
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=508458 ) do require latest
> I-Build of Photon to build properly.
>
> Personally, and from our Red Hat team perspective, I think it's all fine to
> target the latest and greatest: significant value and efforts are put in
> next release, and the quality of Platform milestones is usually quite good,
> so I see no value for my/our use-cases to stick with older versions.
> However, I can understand this can be an issue for some other contributors
> and I would like to avoid breaking them of putting LSP4E in a state that
> would make it hard for them to contribute.
>
> So, from there, there are multiple things we can do. I'll list some
> proposals, but that doesn't mean I like all of them ;) But food for thought
> is always welcome:
> 1. We leave the patches for new features in Gerrit and wait for LSP4E to
> officially support the new version as minimal version
>   ** Pros: backward compatiblity
>   ** Cons: that would extremely slow down the project
> 2. We release LSP4E 0.5.0 soon, and then we declare 0.6.0 stream uses 4.8 as
> minimal target, and development happens only on master for 0.6.0
>   ** Pros: allow to keep in sync with Platform latest improvements
>   ** Cons: after 0.5.0 is released, no new feature in LSP4E for older IDEs
> 3. We release LSP4E 0.5.0 soom, and then we declaire 0.6.0 stream uses 4.8
> as minimal target, and we branch a 0.5.x for those who need it to backpart
> patches and features from 0.6.0.
>    ** Pros: should work for everyone
>    ** Cons: effort in backport
>
> Some important context is that the Eclipse Platform release policy will
> change after Photon, with one release every 3 monthes and some removals of
> deprecated APIs every 3 months. So in any case, all Platform-based projects
> have to be ready for more agility.
>
> My favorite is proposal 2.
> Proposal 1 would be a show-stopper for the project IMO, and proposal 3 is
> IMHO not worth it.
> That said, I could live with proposal 3, but wouldn't personally place any
> effort in backporting and release the 0.5.x. That means whoever needs it
> must feel ready to contribute as much as necessary for this to happen, and
> we should nominate such maintainer as a project co-lead to deal with related
> paperwork.
>
> WDYT?
> --
> Mickael Istria
> Eclipse IDE developer, at Red Hat Developers community
> Elected Committer Representative at the Eclipse Foundation board of
> directors
>
> _______________________________________________
> lsp4e-dev mailing list
> lsp4e-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/lsp4e-dev
>



-- 
Elliotte Rusty Harold
elharo@xxxxxxxxxxx