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