OK let me clarify, First let me wave the -1 so everyone can be calm. I casted -1 because there was no information available on the reasoning and it felt really wrong to do it like that. You referenced a PR in another repo https://github.com/vespa-engine/pyvespa/pull/1229 that I am not sure how I was supposed to find and also still doesn't explain the issue I asked about.
to clarify, no - this does not happen all the time. What happens all the time is a bump of a version in a specific provider or in two providers that are tightly coupled. For example GKE in Google and cncf.kubernetes. Here, we are bumping ssh/sftp due to a provider that is not tightly coupled. You are asking all ssh/sftp users (who are a lot!) to bump version to accommodate vespa users. ssh/sftp are really sensitive providers - they are used by many who run older versions and we should be mindful of that. It's OK to do that but: Bump paramiko lower bound to >=3.5.1 due to adding Vespa provider can **not** be the reason we give to the ssh/sftp users. The reason needs to be something the community will appreciate. For the moment, I can't really tell if the issue is just the release note entry or if there is a way to avoid the change altogether. I still can't find any reference to the discussions you are referring to about the versions and more specifically I did not find anywhere where an answer to why vespa can't specify the paramiko and cryptography in its own toml file. The CI will pick the versions it specifies along with the ones we have in ssh/sftp and will decide on the versions we have in constraints. If there is an issue with the CI - I don't understand what it is and at what PR it was discussed. Can you please point me to it? On Thu, Apr 23, 2026 at 3:05 PM Radu Gheorghe <[email protected]> wrote: > Hi, > > I mentioned this in the PR, that maybe it's OK to modify the CHANGELOG to > say that paramiko was bumped because cryptography was bumped - and that > happened because of security reasons? > > I think that's reasonable to say and is, in fact, the root cause for the > bump. > > All the best, > Radu > > On Thu, Apr 23, 2026 at 2:52 PM Jarek Potiuk <[email protected]> wrote: > > > No. I think we need to solve it here (I commented on it in the thread. > > > > Elad, I'm not sure what problem you are trying to solve. > > > > Would love to solve it here - because usually (-1) is a sign that > something > > is catastrophically wrong with the provider. I'm a bit surprised to see > > (-1) because things were not exactly explained in the PR (but later > > explained in the changelog) there are about a 100 of such bumps in the > last > > year at minimum in various providers, so I am just surprised to see ti. > > > > I discussed some of that with Radu personally and Thomas directly and > some > > of that is in the PR itself. And this happens **all**, **the**, **time** > > that we do such changes. This is one of the biggest benefits of a > monorepo: > > we can solve such issues in a single PR that fixes holistically the > problem > > of installing providers together. > > > > I really look forward to solving it in the way you will be happy - but I > > can't see a reason why suddenly you vote -1 on something that we do all > the > > time so far. We might want to change the approach if you want to - but I > > don't think it's a reason to -1 a provider - that looks like > > extreme overhoot. > > > > J. > > >
