Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request - Product] AWS Lambda runtimes #2806

Closed
jamietanna opened this issue Apr 9, 2023 · 7 comments · Fixed by #3982
Closed

[Request - Product] AWS Lambda runtimes #2806

jamietanna opened this issue Apr 9, 2023 · 7 comments · Fixed by #3982
Labels
request Request for a new tool or changes

Comments

@jamietanna
Copy link
Contributor

jamietanna commented Apr 9, 2023

Full and short name of product

AWS Lambda

Does this product have LTS versions? What are the intervals between each LTS version?

No

What is the website for the product and for its version information?

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

Additional context

AWS Lambda contains a number of runtimes which have different deprecation/end-of-life policies.

I've previously worked on this problem and ended up hardcoding the dates at the time of writing which has the risk of being out of date before too long, so thought of automating this process, perhaps by parsing the HTML.

@jamietanna jamietanna added the request Request for a new tool or changes label Apr 9, 2023
@welcome
Copy link

welcome bot commented Apr 9, 2023

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

@jamietanna jamietanna changed the title AWS Lambda runtimes [Request - ProductAWS Lambda runtimes Apr 9, 2023
@jamietanna jamietanna changed the title [Request - ProductAWS Lambda runtimes [Request - Product] AWS Lambda runtimes Apr 9, 2023
@jamietanna
Copy link
Contributor Author

I've looked at endoflife-date/release-data#127 but that may be blocked by endoflife-date/release-data#51 - instead, does it even need that, or can we just have the scripts work for the YAML in this repo?

@captn3m0
Copy link
Member

The first step is creating a page for the product, setting up automation (for new releases) comes next, and we can look at automating EOL dates after that.

@jamietanna
Copy link
Contributor Author

Cool, thanks! For AWS Lambda runtimes, there's not really an "update" to a runtime (at least made publicly available) but are more treated as released but never updated. Would that still make sense to exist in release-data or instead maybe just in this repo?

@marcwrobel
Copy link
Member

This product looks difficult to document, I am wondering if we shouldn't treat each runtime independently, that would facilitate the maintenance and automation IMO.

Cool, thanks! For AWS Lambda runtimes, there's not really an "update" to a runtime (at least made publicly available) but are more treated as released but never updated. Would that still make sense to exist in release-data or instead maybe just in this repo?

Yes it makes sense. If there is a script in release-data, even if we do not display the latest versions, we will at least be alerted that new releases must be documented (would be similar to #3323 (comment) for example). The process of documenting new releases is manual (for the time being), but relatively easy.

@captn3m0
Copy link
Member

captn3m0 commented Aug 1, 2023

I would prefer separate pages for now, till we can decide on a schema for distinct identifiers for various release cycles. I created a discussion for that here: #3346

@jamietanna
Copy link
Contributor Author

Thanks folks - so I guess we'd have i.e. aws-lambda-nodejs as the product, with nodejs12.x as a cycle?

marcwrobel added a commit that referenced this issue Oct 29, 2023
All runtimes are mixed on the same page. This is not what was previously intented (see #2806 (comment)), but given each runtime has its own identifier I had the feeling this would be much simpler for API users than having multiple product pages (and it makes the automation simpler too).
marcwrobel added a commit that referenced this issue Oct 29, 2023
All runtimes are mixed on the same page. This is not what was previously intented (see #2806 (comment)), but given each runtime has its own identifier I had the feeling this would be much simpler for API users than having multiple product pages (and it makes the automation simpler too).

Closes #2806.
marcwrobel added a commit that referenced this issue Nov 1, 2023
All runtimes are mixed on the same page. This is not what was previously intented (see #2806 (comment)), but given each runtime has its own identifier I had the feeling this would be much simpler for API users than having multiple product pages (and it makes the automation simpler too).

Closes #2806.
marcwrobel added a commit that referenced this issue Nov 23, 2023
All runtimes are mixed on the same page. This is not what was previously intented (see #2806 (comment)), but given each runtime has its own identifier I had the feeling this would be much simpler for API users than having multiple product pages (and it makes the automation simpler too).

Closes #2806.
marcwrobel added a commit that referenced this issue Nov 23, 2023
All runtimes are mixed on the same page. This is not what was previously intended (see #2806 (comment)), but given each runtime has its own identifier I had the feeling this would be much simpler for API users than having multiple product pages (and it makes the automation simpler too).

Closes #2806.

---------

Co-authored-by: Nemo <commits@captnemo.in>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Request for a new tool or changes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants