opened
therealadityashankar
username_0
any version management service requires being able to discover all the available versions,

lets say in a module, I use

```js
import something from "https://deno.land/x/something@1.2.0/main.ts"
```

it'd be nice if I could do something similar to

```sh
curl https://deno.land/x/something@versions
```
if it'd return

```json
{"versions": ["0.0.1", "1.0.0", "1.0.1", "1.1.0", "1.2.0", "2.0", "2.1"]}
```

there's currently no standardised way of discovering all available versions of a file,

currently, for example, [deno-udd](https://github.com/hayd/deno-udd), uses a variety of techniques to find all available versions, including
- checking github releases
- checking https://raw.githubusercontent.com/denoland/deno_website2/master/src/database.json for package releases
- web scraping

apart from the other issues in this (like github's rate limiting), there is no standard, meaning that every person who hosts a file on their site will have to tell deno-udd to be able to support their website, and every other deno version management service to be able to support their website, and like, what may be a standard way in one version management service might not be supported in another

I like the `@versions` method cause is simple, and probably super easy to implement

further, it'd be even better if it could support additional parameters like
```json
{
    "versions": ["0.0.1", "1.0.0", "1.0.1", "1.1.0", "2.0", "2.6.9"],
    "deprecated": ["1.*"],
    "fatal-risk-of-use": ["<1.0.0"],
    "dog-person-wrote-code": false,
    "cat-person-wrote-code": true
}
```

relevant issue https://github.com/hayd/deno-udd/issues/10
@versions to list down all versions of a module [Enhancement]
issue
created
lucacasonato
username_1
As you said GIthub rate limiting prevents us from doing this. We only have 60 server side requests per hour, but 235 modules, with more added every day. That means that at most we can update each modules' versions once every ~4 hours (235 / 60). That is not a great experience for the end user. And it only gets worse with an increase in the available modules.
comment
created
therealadityashankar
username_0
how does deno.land currently retrieve package content, is raw.githubusercontent.com not subject to the same rate limits ?

If the above is true, I guess a temporary alternative could be asking individual package owners to have an versions.txt in the master branch, which could be represented in `@versions`
comment
created
therealadityashankar
username_0
another option - although untested - might be GraphQl github requests, which I believe work with lesser rate limiting restrictions
comment
created
kitsonk
username_2
This should be moved to denoland/deno_website2.
comment