LSP-* versions should be based on the min/max version of LSP

[predragnikolic]

Hello,

LSP is the main package that each LSP-* package imports,
so it makes sense that the version that the LSP-* packages specify, should match the min/max version of LSP,
which is:
ST 3 - 3154 -4069
ST 4 - >=4070

I have noticed the the versions of LSP-* that plugins specify are not consistent, or are sometimes even wrong("sublime_text": "3154 - 4147" - a release for ST3). So I decided to clean that up.

cc @jfcherng, @jwortmann, @rchl, @rwols

[STReviewBot]

Automated testing result: SUCCESS

Packages modified:
  - LSP-css
  - LSP-eslint
  - LSP-html
  - LSP-json
  - LSP-julia
  - LSP-metals
  - LSP-prisma
  - LSP-pyright
  - LSP-serenata
  - LSP-typescript
  - LSP-volar
  - LSP-yaml

[STReviewBot]

Automated testing result: SUCCESS

Packages modified:
  - Chialisp
  - LSP-copilot
  - LSP-cspell
  - LSP-css
  - LSP-eslint
  - LSP-html
  - LSP-json
  - LSP-julia
  - LSP-metals
  - LSP-prisma
  - LSP-pyright
  - LSP-serenata
  - LSP-typescript
  - LSP-volar
  - LSP-yaml

[jwortmann]

This is not possible to change to 4070. I put this on purpose to 4095 because LSP-julia uses sublime.ListInputItem which was introduced with ST 4095.

The 4070 restriction for the main LSP package is mostly meaningless anyway, because I'm almost sure it uses various things from the ST API that were introduced after build 4070. Personally I also don't like the 4070- prefix for the version tags (purely for aesthetic reasons). iirc it was introduced to make it possible to add new release prefixes with increased build numbers whenever new functionality from the ST API gets used in LSP. But apparently this didn't happen in the past and also nobody really cares about it, so I guess it can just stay like this (4070) forever and in the case of any issue reports get filed in the future for the use of API incompatible with older ST builds, we could just fix those gradually with if ST_VERSION > XXXX checks in the code, if possible.

[predragnikolic]

Thanks for pointing that out.

I went through the LSP-* packages again
and checked if other packages use sublime.* apis introduced in later versions of ST and reverted the versions.

[STReviewBot]

Automated testing result: SUCCESS

Packages modified:
  - Chialisp
  - LSP-cspell
  - LSP-css
  - LSP-eslint
  - LSP-html
  - LSP-json
  - LSP-metals
  - LSP-prisma
  - LSP-pyright
  - LSP-serenata
  - LSP-typescript
  - LSP-volar
  - LSP-yaml

[predragnikolic]

Also, if anyone thinks that this should be left as it was, feel free to say it.

I kind of had some urge to do it, because some versions just didn't make sense, but I'm fine with closing the PR if there is no value in it.

[rchl]

Also, if anyone thinks that this should be left as it was, feel free to say it.

I kind of had some urge to do it, because some versions just didn't make sense, but I'm fine with closing the PR is there is no value in it.

I think those changes have no point and potentially even make things worse because there was a ton of new stuff added and changed in 4147 vs. 4069 so it's almost guaranteed that latest LSP code would not run in 4069. The ST3 version has higher chances of working there.