On Wed., Mar. 4, 2020, 05:37 Mickael Istria, <mist...@redhat.com> wrote:
> > > On Wed, Mar 4, 2020 at 3:23 AM Jonah Graham <jo...@kichwacoders.com> > wrote: > >> I have contributed <https://git.eclipse.org/r/#/c/158771/> a snapshot >> <https://download.eclipse.org/lsp4e/0.14.0-snapshots/S202003032032/> of >> 0.14.0 >> <https://projects.eclipse.org/projects/technology.lsp4e/releases/0.14.0> >> for SimRel RC1 today (We can provide a new RC1 contribution before end of >> the day tomorrow - I am not sure what LSP4E's +? day is) >> >> I am concerned that there are 4 different versions of LSP4E in SimRel >> referenced repos at the moment. >> >> These projects contain the following versions in their P2 repos that are >> contributing to SimRel: >> LSP4E - 0.13.1.202003021135 - this is the version that will make it into >> SimRel >> Linuxtools - 0.13.1.202001301838 >> WildWebDeveloper - 0.13.0.201912071343 >> Corrosion - 0.11.0.201909021607 >> > > That's exactly why I usually prefer releasing early and independently from > SimRel schedule: it makes it easier for projects to keep in sync and avoid > the "let's update everything to volatile S-Builds" rush before SimRel and > the need to move to the actual release just after. > That argument would carry more weight if all the projects listed above were contributing to simrel were at least on the most recent release version of LSP4E or newer. Perhaps I am also concerned for nothing, maybe LSP4E is perfectly API stable so that their won't be runtime linkage errors. 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. Perhaps you could start the discussions now for when the next releases are going to be? We can discuss having a window so that things can change. When doing so please also don't underestimate the value of simrel for coordinating API changes across multiple projects. 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. 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. Thanks, Jonah _______________________________________________ > lsp4e-dev mailing list > lsp4e-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/lsp4e-dev >
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/linuxtools-dev
