Fix Debian API URLs

[x70b1]

I would like to make a couple of suggestions.

I want to use the API. The issue here is that the URL is very inconvenient as the path needs to be urlencoded and is generated from the releaseCycle field. Example:

$ curl -sf https://endoflife.date/api/debian/Debian%209%20%22Stretch%22.json | jq

Something like this would be much easier to work with:

curl -sf https://endoflife.date/api/debian/9.json | jq

This means also that you can already understand how the API works, even if you dont know much details about your requesting product. At the moment you have to request the product, urlencode the releaseCycle and generate a new request.
My shorter path would be usable even if you don't know the current release tag. urlencoding is probbaly not a problem with JavaScript. But doing this on a shell is a nightmare. So I split the fields and introduced cycleShortHand for Debian.

Debian 9 is in LTS now. So I removed the 2nd Debian 9 block. But there is also something to discuss. Its not true that there is a non-LTS and a LTS version of a release at the same time. The LTS starts when the support for a release is dropped by the Debian Security Team. The Question is how to handle this? Just add a LTS flag at the end of the official support? Should be EOL date the point when official support is dropped? Or when the LTS is dropped?
An other way could be to add releases like 9-LTS. This is "released" when the official support is dropped.
Here is also another idea for this: #156
Here was this also a topic: #456 I have checked it and there is no need to change something on the system to get LTS support. The apt sources are the same as for the regular stable release.

I have added a some other changes: cat /etc/os-release contains more and better information than lsb_release. I have also added the latest version of 6 and 7. also some typos.

Some of my points also hit other products like Ubuntu.

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines. If you are working on site internals, see https://github.com/endoflife-date/endoflife.date/blob/master/HACKING.md

[captn3m0]

1. For LTS, I think Upcoming LTS with a date #156 is a clean and easy approach that works for most projects. (Not those with relative dates)
2. The "easier URLs" problem is real (one of the reasons I'm still hesitant to move the API from alpha, since any solutions involve a breaking change).

But the current solution has to drop the release names (buster/wheezy) from the text, which are important for Debian. Okay with merging in the intermediate, while we can look for solutions.

Suggestion: How about a nameTemplate field where we can provide a similar template as changeLogTemplate that can use all the release Parameters to label itself? This also works well for Ubuntu I think.

So for Debian, it could look like __RELEASE_CYCLE__ (__CYCLE_SHORTHAND__) __LTSLABEL__ (Where LTSLABEL is (LTS) or ``)

[captn3m0]

Will wait for a while before merging, in case there are other suggestions since this is a breaking change, but LGTM.

Thanks a lot for your contribution 💯!

[x70b1]

The template would be a good solution here. The LTS field with a date would be perfect. 👍

[usta]

are we sure to remove code names ? if it is we also need to make it all ( ubuntu , android , .... ) and it will also lower our visitors from search engines which generally people are searching their code names
If we plan to remove these from name it might be better to add a new column named codename that we will add those names so search engines wont effected
@captn3m0 @BiNZGi

[captn3m0]

See the template plan above, so we'll have it back quickly.

[usta]

@captn3m0 __LTSLABEL__ -> __LTS_LABEL__ other than that it looks good

[welcome]

Congrats on merging your first pull request!

[captn3m0]

#891 is up with initial tempting support to fix these issues. It doesn't work for complicated cases, but the majority is easily covered.