Chris Bloom

@G-Rath I hear what you are saying and understand why it's problematic for not just your use case but for many others as well. > I mean, even just having...

While we are still working on finding a better way to handle the `>` operator in general, GHSA-93q8-gq69-wqmw is included in a list of advisories that we think can be...

@nscuro thank you for bringing this up. The `last_affected` field is relatively new to the spec and was introduced after our initial build out of our OSV transformers. We have...

For additional context, the work we have scheduled will allow us to transform upper bound _inclusive_ ranges (i.e. `

We will also continue to use it for ranges where the upper bound inclusive `

Commented on the wrong issue - please ignore

@oliverchang Thanks for explaining why the current approach could be problematic and for iterating through a number of potential solutions. For starters, I would love to remove our dependence on...

_grumble_ ... thinking about this further, we use `last_known_affected_version_range` to retain enough context about an upper bound that we can determine if it originated as a `

Maybe we can do both options 1 and 2? They serve different purposes, and having both options available would be useful on our side to clean up our round-trip transformation...

Might I suggest that if we're willing to add `last_affected` we also add `last_known_good`, and potentially `last_known_bad`? With those in place we can easily represent `>`, `>=` (i.e. `introduced`), `=`...