search

endoflife-date / endoflife.date

Informative site with EoL dates of everything
https://endoflife.date
MIT License
2.5k stars 778 forks source link

Normalize version numbers in API calls #4879

Open Cohen-Carlisle opened 7 months ago

Cohen-Carlisle commented 7 months ago

Is your feature request related to a problem? Please describe. Yes. Currently, the API is inconsistent (e.g., for React) in that it sometimes requires major.minor and sometimes requires only major in the URL. E.g., React requires major.minor for 18+ but requires only Major for < 18.

Describe the solution you'd like It would be very nice from an api perspective if the API was able to discard overly specific version information. For example, if I call https://endoflife.date/api/react/16.14.json it would be nice to get the response at https://endoflife.date/api/react/16.json instead of a 404. This would let me call with major.minor at all times (e.g., https://endoflife.date/api/react/18.2.json or https://endoflife.date/api/react/16.14.json) and get a valid response instead of having to know the exact cycles (which seems like it may change after a major version release).

Describe alternatives you've considered None of these are currently supported by our tooling, but in theory there are several workarounds (if you completely control the code calling the API)

  1. Call https://endoflife.date/api/${product}.json and do some string comparisons with our version strings to figure out which api path to call.
  2. Retry calls with less specificity (e.g., start with major.minor.patch), and if 404, drop the rightmost part of the version.
  3. Store known patterns in how to call the API (the amount of version numbers of include). This seems more brittle than 1 or 2.
  4. Write very clever regex that uses known patterns to extract the correct api version strings for eol.date. This is both brittle and hard to maintain.

Additional context We are using https://github.com/natecox/corrator to extract software versions from containers and get currency info for them from eol.date. We are not the maintainers and it currently only supports a static regex to extract the version string used to call eol.date.

welcome[bot] commented 7 months ago

Thank you for opening your first issue here :+1:. Be sure to follow the issue template if you chose one.

marcwrobel commented 7 months ago

Hi @Cohen-Carlisle, I don't know if it applies to react, but we try to follow how particular releases are supported by the product vendor. So this type of inconsistency can happen if the vendor changed the way the product is supported (for example if the support was in the past on major, but is now on major.minor).

Having said that, for React I can think of two cases:

  1. Either the support was always on major.minor : in this case the product must be updated to reflect that and it will fix the issue you are facing.
  2. Or it changed over time, and in this case the product is properly documented. So this means we need to do something in the API to accommodate your request.

For the second point, I think it would be hard to specialize the documented releases from major to major.minor. Generalizing major.minor to just major may be a bit simpler, but this must be done only for the latest major.minor. Another solution could be to respond to each specific version (major.minor.patch), but this would require to have an up-to-date list of all versions.

So I agree this would be nice to "normalize" the version number, but except if it's an error in the way the product is documented (case 1) it won't be easy to implement.