Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDocument default OS policy and set default variant per node version #1288
Conversation
|
IMHO we don't need this extra complexity. We worked hard to get to a point were our image tagging give users the most flexibility. Users who want stability should pin to a specific OS and even specific node version while user want to get rolling LTS can do that with tags too. |
If the variant specific configuration is no-go, I'd still like to see the policy documentation part here done in some form. I can write separate PR out of it if there is a common understanding of what is OS update policy. For me it sounds like there is no really a policy the base OS version gets updated. |
tvainika
changed the title
tvainika
force-pushed the
tvainika:default-variant-per-node-version
branch
from
2a6fd32
to
6532375
tvainika commentedJul 6, 2020
The default operating system release used by
nodeimages has not been properly documented, and the policy of updating the operating system release underlying a specificnoderelease has been causing unexpected behavior when the operating system release had been updated. The clearest description of the issue was in #1068, which was closed without properly documenting the maintenance policy.Changes here in
README.mdI'm trying to write down sensible policy of the operating system release. There are arguably also other ways to define the OS release policy than that one.The policy written and implemented causes different default operating system release to be used per nodejs version. In my opinion this makes sense, because the operating system support period and nodejs maintenance period should be in sync as much as possible.
The policy here defines default operating system release of both Debian and Alpine per nodejs version compared to earlier solution of defining the default release shared for all nodejs versions. This allows the operating system support period and nodejs maintenance period to be more in sync. The policy allows changing the underlying default operating system release when specific nodejs version enters LTS maintenance period. IMHO it would make sense to switch default Debian release used with Nodejs v14 to be Debian 10 (buster) instead of Debian 9 (stretch), which it is now, so it does not need to be changed during the Nodejs v14 LTS maintenance period. On the other hand Nodejs v10 LTS maintenance period ends at 2021-04-30, which is earlier than Debian 9 (stretch) extended support, which ends at June 30, 2022, and therefore Nodejs v10 default Debian release should not be changed, just my 0.02 cents. Nodejs v12 LTS maintenance ends at 2022-04-30, which is also before Debian 9 (stretch) extended support ends, which also should not be changed.
I did not analyze Alpine release timeline, but the configuration change here allows also Alpine default tag to be configured per node version.
This also cleans up some chakracore configuration support as it was removed and supporting that complex logic was in conflict of having
configfile per nodejs version.