You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Determine an approach for validating jupyterlab-lsp's bottom pin on jupyter-lsp.
Motivation
Over on conda-forge we raised the discussion of what jupyterlab-lsp's proper bottom pin should be.
Design Ideas
jupyter-lsp >={{ hand-made version }} (status quo)
we have to remember to bump the pin when something (e.g. schema, etc) changes
jupyter-lsp
probably not so good, you kinda never know what you're going to get
jupyter-lsp ==<latest>
probably not so good, means we can't ship a jupyter-lsp without shipping a new jupyterlab-lsp
hasn't happened yet, but a hotfix might need it
whatever we do, we could add a (nightly CI) test which validates a broader matrix of as-installable packages. i really don't know what we'd find... the most likely thing would be bumping a pin, and having to cut a new release, as at least on pip, yanking is not a great option. on conda-forge we can cut a build with an incremented build_number, but this doesn't always solve the problem.
The text was updated successfully, but these errors were encountered:
which reminds me each Sunday that I could increase the bottom version of jupyter-lsp. Maybe it should generate some clever GitHub Actions annotation to show up prominently on CI (without failing a build).
My manual decision process is to bump the pin on minor releases but not on patch releases as in major.minor.patch.
Yeah, thoughtful is probably the best we can do at this point without actually testing old versions. At least we're looking! But seems like we really can't double (or worse) our CI time by testing the bottom pin every push. Since we're building noarch on conda-forge (and noarch we should stay as long as possible!) it can't help out much (e.g. by testing the oldest version and the newest version).
Elevator Pitch
Determine an approach for validating jupyterlab-lsp's bottom pin on jupyter-lsp.
Motivation
Over on conda-forge we raised the discussion of what jupyterlab-lsp's proper bottom pin should be.
Design Ideas
jupyter-lsp >={{ hand-made version }}
(status quo)jupyter-lsp
jupyter-lsp ==<latest>
jupyter-lsp
without shipping a newjupyterlab-lsp
whatever we do, we could add a (nightly CI) test which validates a broader matrix of as-installable packages. i really don't know what we'd find... the most likely thing would be bumping a pin, and having to cut a new release, as at least on pip, yanking is not a great option. on conda-forge we can cut a build with an incremented
build_number
, but this doesn't always solve the problem.The text was updated successfully, but these errors were encountered: