To restate my previous objection - I am fine with releasing off cycle with simrel, just not arbitrarily changing previously announced release dates from some time in the future to tomorrow.
I don't get what the difference is between "off cycle" and "tomorrow".
IMO, we need to be able to release LSP4E whenever we need, even if this is tomorrow. The only reason valid to retain a release of LSP4E is a change depending on an unreleased components (LSP4J or Platform for example).
Are we currently in such a situation.
Perhaps you could start the discussions now for when the next releases are going to be?
What would be the value of deciding releases in advance while we don't even know what changes are going to happen and when? I prefer the project releasing as a reaction to a bunch of interesting changes (and focusing on providing interesting changes) than planning release dates.
The nature of lsp4j trying to apply a schema fundamentally designed for _javascript_ to a strongly typed language means that we are likely to have this in the future again.
Semantic versioning and automated API Analysis are what we want can help here. A synchronized release date doesn't prevent from any bug.
In the meantime, consumers of lsp4e/j should probably have version ranges on their dependencies. And lsp4e/j should make sure not to break provisional api in maintenance releases.
Right.
Both projects are still incubation and do not yet announce clearly their APIs. Some consumers may take the risk of using incorrect APIs (but that's their issue). The issue is that API Analysis cannot work while 1. LSP4J doesn't use Semantic Versioning as well and 2. project is incubating (as we may need to bump major versions).
Do you know if LSP4J has plans to graduate and use Semantic Versioning to highlight broken APIs soon?
