Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lsp4e-dev] Can we release soon?
There is a long discussion below - summary is I am fine with releasing early, just not changing release date from "three weeks from now" to "tomorrow". If you want to change it to one week from now, I have no objection. 


On Thu, 27 Feb 2020 at 14:33, Mickael Istria <mistria@xxxxxxxxxx> wrote:


On Thu, Feb 27, 2020 at 8:13 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
I would prefer that we release when we previously announced - i.e. when all the other simrel contributions release.

I personally cannot deal correctly with SimRel and deadlines, as I don't know in advance when I'm available or not, and following SimRel schedule so closely IMO generates a lot of stress for no value, and actually put also a lot of stress on downstream projects that need to update to milestones and cannot build a final target platform before the SimRel date.

I understand this (all the more that I am doing epp releng now).
 

Personally I really don't like that LSP4J releases just before everyone else - and I think for example this issue in LSP4J https://github.com/eclipse/lsp4j/issues/415 is part of why.

I don't think the release date changes anything here. It's all about backward compatibility and conformance to specification, the date wouldn't have prevented such issue from occurring.

The release date doesn't change anything - but having Release Candidates and not changing release dates close to the actual release does. Also, having all the projects on the same release cadence does help this integration testing.

 
 
For now based on a bit of history and that Maven publishing "rules" are different than how p2 works makes it logistically hard, but I would rather figure out how to realign LSP4J than have LSP4E also join the release early route.

IMO, the LSP4E stack is much saner by releasing early/often than by following SimRel. SimRel doesn't bring much value to that stack, see for example Wild Web Developer that gets released almost every month against the latest version of Platform.

We can release early and often, but lets give our adapters/extenders sufficient notice.
 

(PS We could just release an extra time if needed, i.e. 0.14.0 today and 0.14.1 on 18 March, but with the additional issue of APIs changing, that is non-trivial too.)

Which APIs are changing in LSP4J/LSP4E that we need to act upon for next LSP4E release?
If LSP4J is "fragile", we can just deal with version range to only declare compatibility with a specific version of LSP4J.

LSP4J isn't fragile - but the 0.9.0 does bring in lots of API changes to match the specification changes of LSP and DAP.
 

Is LSP4J 0.9.0 released?

No - it is due today, but I am trying to resolve whether the open items with milestones of  0.9.0 are critical and should stop shipment. 
 
Can we update the target platfrom accordingly?

 
Should we just put [0.9.0,0.9.1) as version range if there is a strong risk of broken backward compatibility in future LSP4J release?

[0.9.0,0.10.0) would make sense - there won't be API changes between 0.9.0 and 0.9.1 as that would be way to hard for adopters to manage IMHO.

Thanks,
Jonah
 
_______________________________________________
lsp4e-dev mailing list
lsp4e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lsp4e-dev

Back to the top