yank [email protected] #119607
yank [email protected] #119607
Conversation
|
|
|
Not sure I see how is yanking suitable for malware situations... Then, best would be to just remove the version so that nobody installs it anymore. While in these scenarios, yanking seems like a clean way to say "please don't resolve to this version in the future, but if you already did that – fine, everything will continue working". Exactly what's needed :) |
|
Suppose that someone releases a version Foo.jl version 1.1.0, but they actually made a breaking change (and thus they should have actually released Foo 2.0.0). In that case, if a downstream user (that has This is the opposite situation. Someone released a version Bar.jl version 0.7.0, but they didn't actually have any breaking changes, and thus they could have (and should have) released a Bar 0.6.x. In this case, if a downstream user installs Bar 0.7.0, their code won't actually break (because Bar 0.7.0 didn't have any breaking changes). In this case, because there is no risk of a downstream user having their code break, we do not need to yank Bar 0.7.0 in the registry. |
I'm not sure if I fully appreciated the specific way "yanking" is implemented, as opposed to deleting/reverting a package or release. I do agree that actual hypothetical malware should be purged from the registry in a way that makes it impossible to install.
That's not really necessary, and arguably violates SemVer. The SemVer specification explicitly discusses this particular situation:
Maybe the "yanking" feature in the registry was intended as a way to implement "inform your users"? If so, that would be a good thing, but I've seen situations recently where things got screwed up because of a yanked package. If not, I still think we should almost never yank anything. There might be some situations related to wrong compat bounds where mistakes can't be repaired within SemVer, but I'm not even sure about that. |
|
Just to conclude this: the intended behavior of yanking is described in the General Registry README. The way it is described there, it should generally be okay to yank "broken" releases under the conditions described there. Note that this PR is not one of those conditions. Generally speaking, an accidental major release that actually wasn't breaking is certainly unfortunate / confusing (in the sense of "unexpected"), but it's not a violation of SemVer. There's nothing that can be done that wouldn't violate SemVer except to just keep going from the major release. I would also point out that StructArrays is pre-1.0, so a change from v0.6 to v0.7 is actually not breaking (despite It might be worth looking at whether At this time, it's unclear whether This might be a moot point, and I also might be misunderstanding something, but the reasoning for when yanking is necessary seems off to me. Specifically,
seems just wrong: it is never invalid to fix a bug in a patch bump. The only way to fix the bug in that example is to revert the feature, but that doesn't make it breaking/not-a-bugfix. The correct way to handle the "compat bounds too wide" example is to make two bugfix releases: one that reverts the previous release (but keeps the compat bound), and then one that re-applies the previous release but also fixes the compat bound. So, it's not necessary to yank anything, although I certainly don't object to yanking the broken release assuming yanking behaves as described. |
Not really sure what you mean here?
That's definitely not how the Julia ecosystem works, there are lots of pre-1.0 packages with stable API. There's really no difference between 0.3.x and 3.x.y in that regard, other than the latter providing an extra number.
Same, not how Pkg works. It definitely treats 0.x to 1.0 as a breaking change. Such a bump can make sense when one feels the need for an extra number in the version, but otherwise it doesn't matter if the versions go 0.1, 0.2, 0.3, ..., 0.23 or 1, 2, 3, ..., 23. |
I'd really want to make a distinction (maybe an overly subtle / hairsplitting one) between what
There shouldn't be! SemVer specifically says that a package does not have a stable API if it is pre-1.0. This isn't just something where we can just say "Julia uses a minor variation of SemVer". Pre-1.0 versions are a core part of the SemVer philosophy, with a specific meaning. Disregarding that is completely antithetical to SemVer.
I couldn't disagree more! There is a very fundamental difference between the It's fine for Julia to have some minor variations on top of SemVer, like making an additional distinction between |
|
That's definitely a subjective view, not the fundamental truth.
But... Julia Pkg differs from semver in this exact aspect, in handling 0.x versions.
Doesn't really feel like this sentiment is universally shared by the Julia community, judging by a lot of stable packages using 0.x versions. It's fine to have this opinion and follow this version scheme – but that's clearly not the only opinion.
Why not have them? Julia Pkg version treatment is very consistent, without special casing: changing the first non-zero version means a breaking/incompatible release. That's it! PS: sorry to the maintainers, I guess this discussion is really not about this specific PR anymore :) |
|
Back from that extended discussion – I think I have a specific question to @DilumAluthge regarding this PR :)
I assumed we don't need to do anything extra, can just go on with StructArrays development as before. And technically everything does work fine, but only as long as people don't switch from Isn't it exactly the problem supposed to be resolved by yanking? "The version is still there if you already resolved before, but new resolves won't consider it, avoiding confusion". |
|
My reading of how yanking is supposed to work is that
I don't think that's a good way to handle this. Specifically, you will never be able to release another version |
|
If the yanking has become as strict as you say, I struggle to see any usecase for it anymore. Malware? Remove the release completely. Wrong compat bounds? Change them in the registry. Wasn't the motivation for yanking being able to avoid Pkg resolving new envs with an erroneously tagged release? If v0.7.0 was just yanked here, no additional changes would be required, neither from the StructArray side nor from the users. Now, instead, further actions are required from both. |
I'm not sure it has "become" strict… I don't think it's changed (but I'm not sure about the history). I'm only reacting to how it is currently described in the README.
Not as far as I can tell (how it's currently documented). It's to (optionally) mark a release as "broken" after a patch release to fix the broken release, or to deal with the "special category of bugged releases" described in the README.
I don't think that's possible. That would break re-instantiating existing environments, and "reproducibility" is basically the core tenet of General. It would be fine in a LocalRegistry that didn't have such strict rules. Releases are basically immutable. Quite honestly, I don't think yanking is really ever necessary. Even in the "special category" of compat bound issues. I think these can be fixed entirely within SemVer by making two immediate bugfix releases (I might be wrong). But yanking still seems like a good way to attach a "broken" tag to a particular release. So it's probably helpful to have, as a feature.
Does the CompatHelper bot take into account yanking (i.e., would yanking stop CompatHelper prompting peopel to update their compat bounds to But you'd still have to make The bottom line is that yanking does not "undo" a release. There is absolutely no way to undo a release except to completely delete it from the registry, which would only be done for malware, would break the reproducibility promise of General, and has never happend. |
This is not just routinely done, but even planned to make more straightforward - #104849.
Pretty sure it does take it into account.
Don't see any issues with that whatsoever. It would be a breaking version, that's it – be it 0.7 or 0.8 or 0.9 doesn't really matter. |
You seem to be right, e.g., #115069
I don't get how that doesn't break reproducibility. But that's a discussion I'll take over there…
Then I guess |
|
Changed my mind on reopening this, based on the discussion in JuliaArrays/StructArrays.jl#321 If people have already updated their compat bounds to Of course, if @DilumAluthge still wants to re-open/merge this after all of this discussion, that's okay with me. 🤷 P.S.: If you're going the backport route, then there's not going to be any confusion about |
|
Would still be nice to get a response from General maintainers (@DilumAluthge @giordano @LilithHafner ?) regarding this. The yanking situation is quite confusing... On one hand, there's a "common sense" understanding I had
and the fact that yanking versions is routinely done here. These sides seem to be in a conflict, so would be happy to hear where my understanding is wrong :) |
|
My thinking is that if user can end up with broken code, then it's probably worth yanking in the registry. But in this case nobody's code will be broken if they end up with [email protected], so it doesn't seem like we need to yank it in the registry. @giordano @fredrikekre Any thoughts here? |
The version was tagged as breaking but actually isn't. To fix that, it has been released as 0.6.20 afterwards (same exact content).
Meanwhile, 0.7.0 should probably be yanked to avoid further confusion – this PR.