This patch release is to get over the fact that 1.9.0 clients are bad. Ideally we would yank that client release from PyPI and do something similar on Maven Central. I would appreciate some links to: • How to yank from PyPI • How to deprecate or delete on Maven Central (via Sonatype OSS). Thanks if you can provide clues!

re: yanking on pypi: https://snarky.ca/what-to-do-when-you-botch-a-release-on-pypi/

Cool, thanks! Now I just need to figure out how to get keys to our PyPI account -- normally only our CD has them, to prevent humans from touching lakeFS releases 🙂

you cant indeed

Yeah, ouch. Probably not important enough to do, especially given that I'd be limited in which repositories I could use. I doubt Sonatype would let me.

you could even use a github repository, in your organization, as custom maven repo

Thanks, I had a look and it's definitely a great way to do it! I still worry about hassle to our users. As one example: I've seen Spark clusters that are allowed to access some websites but not others. Going with the mainstream means not worrying about this. In this event I don't think the advantages are that compelling.

for gradle users, it's just a matter of a single line, though

Oh sure, for many cases this is a great solution! But Spark and other Hadoop-style clusters are also a use-case, and probably the most common one in the JVM world. In corporate settings not all websites will be accessible from a cluster. I would like to make this decision explicit. The pro to switch to hosting jars on GitHub is to allow us to future. revoke bad versions. The cons are that it introduces a new dependency for our users (a separate hosting service for lakeFS jars), and that it will surprise our users because pulling versions is not common in the Maven world. Our users pay the costs immediately, and we can always inform users they need to upgrade by side channels. If you disagree, let's open an issue and discuss there. Obviously actual numbers of users and configurations for multiple package managers will overrule whatever I have to say.

why dont you simply implement a way in CD to mark yanked releases using the "good" credentials? And then implement the appropriate controls in your org (i.e. 2-people approval or whatever) Can be as hacky as adding a file named 1.9.0.yanked on top of the 1.9.0 "branch" which gets auto-built and released but whatever for java no idea, implement a "public" blacklisting API which you query when creating the client and shows hard-to-miss warnings when detected?, you could even implement this in maven central to avoid being network-firewalled but its vhacky. I.e. you can create a new artifaced called "yanked-lakefs" and if your current version is in that repo, just throw a lot of warnings during lakefs initialization

Hi, thanks, these are all good ideas! Unfortunately Maven packages in Java have no "installation" phase. Worse, initialization occurs on each Spark worker, not just on the driver -- and network access from there will definitely be frowned upon. Given the low risk combined with the ecosystem expectation of almost never pulling packages, I believe we should do nothing to yank the package from Maven Central.

Ariel, to sum up, 1.9.0 on Maven Central should be avoided? If I need to use the API, shall I pull 1.8.0?

Please. And I'll push 1.9.1 with this fix. In any case it's not something you'd notice.

I can confirm I can pull it