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 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.
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.
(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.
Is LSP4J 0.9.0 released? 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?
