Version 10.0 yanked

[Zarthus]

Hi,

We noticed version 10.x was yanked,

But I couldn't find a reference on why, was it a functional issue or a security issue that led to it being yanked?

In addition, is it safe to downgrade from 10.x to 9.x of would you recommend staying on 10.0.3.rc

[ilyakatz]

It was a functional issue (see #181 (comment)).

TLDR; Version 10 was an update that was supposed to allow multi-database environments. But it cause may problems for people and could actually produce some undesired results so it was safest to yank it. If your env is a single database, I would recommend v9. V10 will likely change a lot based on discussion (see above)

[Zarthus]

Thank you :)

[bmulholland]

@ilyakatz Thanks for the heads up. We'll downgrade to V9. Is there a version constraint we can use in our Gemfile that will allow upgrading to the stable version, whenever it's ready? Currently bundle upgrademoves us to an RC for V10, which it seems you don't recommend. Or how will we know when we can remove a constraint of e.g. "<10"? Happy to subscribe to an issue or something.

[wildmaples]

@bmulholland I plan on updating this issue while we work through some bugs / clean up - #268

[bmulholland]

@wildmaples Thanks for your work and the fixes so far! The issue you suggested I follow, #268, is closed now, but the you suggested I follow that PR for is unaddressed.

As I mentioned above, I want to make sure that we'll get new versions that are released -- but obviously not the broken v10 releases. Right now, to avoid the v10 issues, I have gem "data_migrate", "<10" in my Gemfile. However, that means that we won't upgrade to any versions after v9, if/when they're released. I need either a PR to follow that will tell me when I can remove the pin (I had thought that was #268, but I guess not), or a version pin to use that doesn't allow bad versions while allowing future good v10s (maybe "<10 or >10.0"? "!= 10.0.0, 10.0.1, 10.0.2"?). What do you suggest?

[Zarthus]

@bmulholland - our solution for this is using Renovate, BTW - also worth exploring if your team does not use this yet :)

[bmulholland]

Sorry that I'm not explaining this well! Yes, we use those tools, and that doesn't solve my problem :). We still need to decide what versions to ignore, right?

For us, the source of truth for which versions we will upgrade is our Gemfile. It could also be Renovate PRs that we close, so it ignores those package versions. The question is still the same: what versions of data-migrate are we ignoring?

For example, if we used Renovate for this, it would probably create a PR to upgrade data-migrate to v10. We'd close that, of course -- and then Renovate won't suggest that we upgrade to the major version v10 again. It ignores all of v10 for that. So, if a version 10.1 of this package, with the issues addressed, is released, we wouldn't be notified about that by Renovate. No PR upgrade would be created for data-migrate until v11, since all of v10 is ignored. Maybe that's even the case for your repo?

So my question is just: do we ignore all of the v10 major release, such that v11 would be the next good version of data-migrate? Will there be a 10.1.x release that we'd want to upgrade to? Alternatively, is it possible that there's a version 10.1.x that includes some of the yanked code that we don't want to upgrade to? And if there isn't a decision on that right now (totally cool!), how can I learn about that decision when it's made?

I hope this makes it clear, but let me know if I can explain it a different way.

[ilyakatz]

I propose we skip V10 to make it easier. @wildmaples is working on updates to v9 and if we ever need a breaking change, I say we go straight to v11. What do you think?

[Zarthus]

@bmulholland

Since the versions are yanked there wouldn't be a Renovate MR (or gemfile specification) to upgrade to. They no longer are attainable (except for 10.0.3.rc, 10.0.0.rc1)

For example, if we used Renovate for this, it would probably create a PR to upgrade data-migrate to v10. We'd close that, of course

I think I roughly see your concern but I think it only applies for Gemfiles that already had interesting constraints >= 9, latest, or blindly upgrading major versions without testing. If version 10.0.3 or 10.1.0 would be released today with all problems fixed, An update would only bring you to that version, and not 10.0.0)

That said, maybe I'm underestimating the risk; the most error-prone-less thing to do is probably to indeed move on with the next major being v11, even if it saves a single user that's probably worth it.

Constraints like ^9.1 or ~9.1 (or =9.1.0) are probably the most commonplace and would never have you accidentally upgrade major versions.

[bmulholland]

Okay actually I thought v10.0.2 was still out there. I'd checked that several times, but only locally (by removing the gem constraint and running bundle upgrade). It would have been better to double check Rubygems...

Turns out v10.0.2 was cached on my machine. I had to run bundle clean --force to stop bundler from upgrading the package. I guess there's no mechanism to invalidate local caches when a gem is yanked? There's a better likelihood that Dependabot/Renovate/Depfu handle yanked packages properly.

That changes all of what I said above. You're right that we can remove the version pin and there's no action needed from you here. Thanks for sticking with me through that. I guess bundler hasn't solved one of the two hard problems in computer science...

I do agree about just skipping v10, and using v11 for the next release. Seems like low effort for potentially saving someone's time. Nice idea.