Tony Kelman

Would this be mutually exclusive, with only one package allowed to actively satisfy the dependency at a time?

The reason for distinguishing a compatibility-only change from a patch change is that you may need to make the former long after the fact when there have already been later...

> If the latest patch release always supersedes previous ones in the the same major-minor series This is not a good idea, as I've said before - there's not a...

Yes, that seems like a mostly equivalent way of accomplishing the same thing as modifying compatibility in metadata. It records more history permanently (not just in git history), maybe that...

I do think we should keep a log of version history used by local registry copies over time, so you could feasibly implement an "undo" of a global update operation....

If a compatibility-only change can be done only at the registry level without needing the source to change at all, then there's no need for a branch for a compatibility...

What qualifies as a bugfix is not always clear cut either. In fixing one bug, you can often accidentally (or intentionally!) break something else that downstream users were depending on....

The problem is the "broken patch" is broken from the perspective of downstream users who were using the old api, but intended as a new api by the upstream author....

You are proposing making it impossible to declare version compatibility bounds at patch granularity. That's necessary in the case above, where package B depends on package A, which is at...

Splitting a discussion without posting to that effect in the discussion itself isn't terribly effective. Compatibility constraints are either correct, too tight, or too loose with respect to the time...