releaseDate incorrectly overridden by latest.py

[marcwrobel]

latest.py incorrectly overrides releaseDate to the first known version of the cycle, even if this first release is not a x.y.0. Maybe there are some cases where it is useful, but usually it is wrong.

This issue has bee seen on :

• Bump _data/release-data from 931657b to e0dbbc1 #2151 (comment)
• Bump _data/release-data from dfc7b98 to 1878c6e #2146 (comment)
• Bump _data/release-data from 75a54c4 to 05ea763 #2129 (comment)

[captn3m0]

Any suggestions on how to catch for this? Two suggestions:

1. Support pinning of certain fields. I wanted a simple Z:

releaseDate: 2022-01-01Z

Since the YAML spec calls for ISO8601, I thought of using the Z timezone identifier to keep it as a valid ISO date (2022-01-01Z), but it didn't seem to be supported in the Ruby/Python world, despite being a valid timestamp: https://dencode.com/date/iso8601?v=2022-01-01Z&tz=America%2FNew_York

yaml.load("date: 2022-01-01")['date'].__class__
<class 'datetime.date'>
yaml.load("date: 2022-01-01Z")['date'].__class__
<class 'str'>

""" Same results with ruamel
YAML().load("date: 2022-01-01Z")['date'].__class__
<class 'str'>
YAML().load("date: 2022-01-01")['date'].__class__
<class 'datetime.date'>

Had filed an issue for pyyaml here

irb(main):005:0> YAML.unsafe_load("date: 2022-01-01")
=> {"date"=>#<Date: 2022-01-01 ((2459581j,0s,0n),+0s,-Infj)>}
irb(main):006:0> YAML.unsafe_load("date: 2022-01-01Z")
=> {"date"=>"2022-01-01Z"}

Maybe a separate freeze: [releaseDate] key on the release itself, but that doesn't feel elegant.

2. Avoid upgrading releaseDates (going from an earlier to later date) using the automation. Don't like this option, since there are cases where this is required.

[captn3m0]

We could support Z with custom tooling, but we rely on dates being parsed as date in a bunch of places (latest.py, Jekyll etc).

[marcwrobel]

The simpler solution would be to ignore the releaseDate update if the version is not the first of its cycle. Deciding if a given version is the first of its cycle is the complex part, because I doubt something like version.endsWith('.0') is working for all products.

[captn3m0]

We could add a firstVersion field to help it decide

[marcwrobel]

It could be a solution, but I do not like it. Let's see if we can make things better just by introducing a new rule such as :

• if first version of the cycle is not a .0, then do not update releaseDate,
• or if the diff between the two date is to big (such as more than a month) then do not update releaseDate.

We also could inject missing versions on release-data side ? For example by adding more configuration in the auto configuration :

auto:
-    git: xxx
     injectVersions:
         1.0.0: YYYY-MM-DD

[marcwrobel]

Used the ìnject missing versions on release-data side, will be simpler to handle with endoflife-date/release-data#51, but it will not be available soon. Closing this for now.