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

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey!

I fully support the idea of moving towards Photon as a minimal requirement and are generally happy about (2).

There is only one situation for which I don’t have a solution in mind yet. Maybe you have?

Lets assume:
- LSP4E 0.6.0 requires Photon bundles
- One of my components use LSP4E
- That component should be installable into an Eclipse 4.7 (that has LSP4E 0.5.0 already installed)

I would install/update my component from a p2 repo that would contain LSP4E 0.6.0.
But when installing this into Eclipse 4.7 (from that repo), I would like to NOT get LSP4E updated to 0.6.0 (even though it is in the p2 repo) - but the install process should not mention anything, but proceed smoothly.

Is it possible to define the dependencies on the LSP4E side in a way that this install/update path works smoothly?

Cheers,
-Martin




> Am 20.12.2017 um 12:05 schrieb Mickael Istria <mistria@xxxxxxxxxx>:
> 
> 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