Question about the automation actions

[Evernow]

Hi.

For the automatic update github actions setup, does all the Ruby scripts do is update the appropriate json files, and then commit? I ask as I am not familiar with Ruby, but I can automate a few releases using Python.

Wondering if it's appropriate for a Python script to be run in the "Update Release data" action after Ruby, which simply updates the json it wants to, and then the rest of the action can do the work of updating the website.

[captn3m0]

Documented everything here: https://github.com/endoflife-date/endoflife.date/wiki/Automation#release-data

Yes, Python is possible, especially for custom releases that aren't already supported.

You can see the two scripts here as an example: https://github.com/endoflife-date/release-data/tree/main/src and file a similar PR.

[captn3m0]

I felt the need for doing changelog links in release-data as well 👍🏽, but wanted to keep the release-data repository simple for now (just releases and dates).

Can look into this later perhaps, just add a note to the talk page when you find this might help.

[Evernow]

@captn3m0

Hmm, generate a corresponding JSON and we can maybe adopt both?

I believe a JSON format such as this would be easier to manage by custom automators like the one I proposed:

{"2.1": 
	{"latest": "zfs-2.1.4",
	 "released": "2022-03-23",
	 "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-2.1.4"
	 "older-releases": {
	  "2.1.0": "2021-07-02",
	  "2.1.1": "2021-09-16",
	  "2.1.2": "2021-12-15",
	  "2.1.3": "2022-03-10"}								
	},
"2.0": 
	{"latest": "zfs-2.0.7",
	 "released": "2022-03-23",
	 "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-2.1.4"
	 "older-releases": {
	  "2.1.0": "2021-07-02",
	  "2.1.1": "2021-09-16",
	  "2.1.2": "2021-12-15",
	  "2.1.3": "2022-03-10"}								
	},
"0.8": 
	{"latest": "zfs-0.8.6",
	 "released": "2022-03-23",
	 "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-2.1.4"
	 "older-releases": {
	  "2.1.0": "2021-07-02",
	  "2.1.1": "2021-09-16",
	  "2.1.2": "2021-12-15",
	  "2.1.3": "2022-03-10"}								
	}}

(Note this is an example, data is wrong, just for demonstration)

Motivation behind this is that having older releases in the same categories as current is not very useful, and this approach would also allow to very easily update specific branches.

Also I want to emphasize the key values for each branch are not necessarily numerical, instead they correspond to the release name each one has, for example for Ubuntu 22.04 the key for that branch would be " 22.04 'Jammy Jellyfish' (LTS)"

[captn3m0]

the key values for each branch are not necessarily numerical, instead they correspond to the release name each one has

I'd prefer this to match the releaseCycle, as that works best for automation. We can have a releaseLabel key underneath.

"older-releases": {

My intent with the release-data repo was to make this a canonical source of release information for various projects. (Starting with just the release date). Moving older-releases underneath a specific cycles dilutes that usecase. I'd much rather cover all the releases, and provide as much information about each release as possible.

So, our usual keys (link, releaseDate, eol, lts) wherever possible across each of the release.

Rest looks like a good suggestion. I think I can incorporate some of this already.

[Evernow]

@captn3m0

I'd prefer this to match the releaseCycle, as that works best for automation. We can have a releaseLabel key underneath.

That works.

My intent with the release-data repo was to make this a canonical source of release information for various projects. (Starting with just the release date). Moving older-releases underneath a specific cycles dilutes that usecase. I'd much rather cover all the releases, and provide as much information about each release as possible.

So instead of that approach of nested dictionaries for every releaseCycle you're thinking something like this:

{
  "0.8.4": {"released": "2020-05-12", "releaseCycle": "08", "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-0.8.4"},
  "0.8.5": {"released": "2020-10-06", "releaseCycle": "08", "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-0.8.5"},
  "0.8.6": {"released": "2020-12-14", "releaseCycle": "08", "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-0.8.6"},
  "2.1.3": {"released": "2022-03-10", "releaseCycle": "21", "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-2.1.3"},
  "2.1.4": {"released": "2022-03-23", "releaseCycle": "21", "changelog link" : "https://github.com/openzfs/zfs/releases/tag/zfs-2.1.4"}
}

It would be repeating a lot of info (we would be having the info of each branch for each release of said branch), but manageable assuming you're ok with the process of going through every item in the json to find the latest release of a given releaseCycle for cases such as NVIDIA where the latest release cannot be determined by simply looking at the dictionary keys.

[captn3m0]

assuming you're ok with the process of going through every item in the json to find the latest release of a given releaseCycle

already doing that to pick the latest, releaseDate, and latestReleaseDate columns. Want to make this matching a bit more configurable via templating, but haven't needed that yet. The code isn't very performant but it only runs once a day, so it's good enough.