[CakePHP] Fix and improve product releases and description

[marcwrobel]

• document EOL policy,
• simplify the product description.
• remove all minor versions and only track major versions,
• update releasePolicyLink with a more suitable link,
• update 1.x release using https://github.com/cakephp/cakephp/releases/tag/1.3.21,
• update 2.x and 3.x releases using https://github.com/cakephp/cakephp/wiki,
• remove codename and releaseLabel, it was only available on the latest minor release and not widely used.

[usta]

A big -1 👎 from myside to remove middle/old versions data
We need to implement a hide system for the versions which are not supported anymore
And btw we got a core cakephp dev here we can take asistance if we need info about anything [ he helped to
enter someparts of this product to here ) => @ravage84 ]

[usta]

And if it is possible could we at least comment out those old version info instead of removing them
[ maybe we implement that archive/hide old version system and we might need those
dates again later [i know that we can still take them back from git history but feeling a bit sad to
remove that hand entered values :) ]

[captn3m0]

Also see #1707, and #1708. I think we should collapse all older (<=3) releases to one-row-per-major-release, and keep minor releases listed for the latest one.

[usta]

then ok i didnt see that PR before :)

[ravage84]

@marcwrobel thank you for trying to improve the EOL page of CakePHP.

What was your reasoning for deleting all the entered older releases?

This PR changes so many unrelated things about this page. I would prefer to have smaller but more distinct PRs. This way, we do not have to discuss about the whole "package" in one go.
My experience in various OSS projects is that these smaller PRs lead to faster merges, less heated discussions.

Disclaimer: Yes, I am one of the core members of the CakePHP project.

[ravage84]

@usta , @captn3m0
My stance as an EOL dateproject outsider:

• All data you have in a structured way can be used in some way.
• All data you either do not have or do not have in a structured way cannot be easily and efficiently used.

My understanding of the the EOL date project was that we collect data about releases branches/channels and amend them with EOL data that normally isn't available anywhere or easily findable.

In the CakePHP team, we discussed to use the collective data for advanced means.

If you now want to only present the major release data, a lot of historic info is lost.
If that is the case, I'm not sure I (and likely others) still find the EOL date project as valuable as I did before.

I do not understand all the "hate" towards this historc data. 🤷

[marcwrobel]

Wow, it seems this PR is attracting a lot of attention ! Let me explain the reasoning behind all that changes (which is just a proposal to be discussed). And sorry that I did not do it in the first place in the PR description.

My first intention was to fix the current CakePHP data, which is obviously wrong (see #2262 and https://endoflife.date/cakephp).

Then looking at https://endoflife.date/cakephp I thought I could improve the page description. Which led me to have a look at various ressources about the CakePHP release / EOL policy. I looked especially at the release dates (https://bakery.cakephp.org/categories/release.html or https://github.com/cakephp/cakephp/releases) and saw that :

• multiple major branches are maintained at the same time,
• for each major branch the released version are mostly linear, so :
  • once a patch version is released, it replaces the previous patch version
  • once a minor version is released, it replaces the previous minor version. The only exceptions I found in the last five years to that "rule" are for security fixes (https://bakery.cakephp.org/2023/01/06/cakephp_4211_4311_4410_released.html, https://bakery.cakephp.org/2019/04/23/cakephp_377_3615_3518_released.html, https://bakery.cakephp.org/2018/05/20/cakephp_364_3517_3414_released.html, https://bakery.cakephp.org/2018/04/27/cakephp_362_released.html).

So I came to the conclusion that, excluding the few exceptions (four in five years is not much), CakePHP release cycles are more attached to the major version than to the minor.

I am not the lead of endoflife.date (so @captn3m0 correct me if I am wrong), but here is how I understood the goals of endoflife.date :

• Main goal : provide EOL dates and support lifecycles for product in an understandable and succinct manner (=> the release table).
• Main goal : provide a clear information about the release / EOL policy (=> product description).
• Future / secondary goal : provide informations about individual releases (=> to be implemented at the API level or in https://github.com/endoflife-date/release-data ?)

This led me to consider the removal of intermediate minor versions and the rewrite of the product description. But, as I said earlier I am in no way the lead of the project so this PR is just a change proposal and it is open for discussion (like we are doing now).

Having said that you are absolutely right @ravage84: I should have done smaller PRs. So I will split this one into multiple PRs, when I have some time this week, so :

• we can have more focused discussions about the changes,
• to integrate the feedback already provided by @captn3m0.

I will also keep this PR open for now (in draft) to keep the discussion open. This is indeed quite interesting to have multiple viewpoints on what should be an "ideal" product page.

[ravage84]

@marcwrobel thank you for the reasoning.

My first intention was to fix the current CakePHP data, which is obviously wrong (see #2262 and https://endoflife.date/cakephp).

What data points do you refer to, which are (supposedly) obviously wrong?
May be some are just outdated?

* multiple major branches are maintained at the same time,

* for each major branch the released version are mostly linear, so :
  
  * once a patch version is released, it replaces the previous patch version
  * once a minor version is released, it replaces the previous minor version. The only exceptions I found in the last five years to that "rule" are for security fixes (https://bakery.cakephp.org/2023/01/06/cakephp_4211_4311_4410_released.html,  https://bakery.cakephp.org/2019/04/23/cakephp_377_3615_3518_released.html, https://bakery.cakephp.org/2018/05/20/cakephp_364_3517_3414_released.html, https://bakery.cakephp.org/2018/04/27/cakephp_362_released.html).

That is a correct observation.

Minor releases still receive security updates.
I'm not sure we have a hard rule for what time span, though.
The [recent security issue]((https://bakery.cakephp.org/2023/01/06/cakephp_4211_4311_4410_released.html,) wasn't patched for CakePHP 4.0 & 4.1, for example.

So I came to the conclusion that, excluding the few exceptions (four in five years is not much), CakePHP release cycles are more attached to the major version than to the minor.

Understandable and mostly correct.

* Future / secondary goal : provide informations about individual releases (=> to be implemented at the API level or in https://github.com/endoflife-date/release-data ?)

The future starts today. Data available removed today can't be provided in the futrue without re-entering it.

So I will split this one into multiple PRs, when I have some time this week, so :

• we can have more focused discussions about the changes,
• to integrate the feedback already provided by @captn3m0.

I will also keep this PR open for now (in draft) to keep the discussion open. This is indeed quite interesting to have multiple viewpoints on what should be an "ideal" product page.

@marcwrobel thanks for your efforst

[marcwrobel]

What data points do you refer to, which are (supposedly) obviously wrong?

On https://endoflife.date/cakephp :

• 4.3 is marked actively supported but is also EOL. That cannot be possible.
• 4.2 is marked EOL, but there is still security patches (https://bakery.cakephp.org/2023/01/06/cakephp_4211_4311_4410_released.html)
• 2.10 end of support is wrong (should be 2020-12-15 according to https://github.com/cakephp/cakephp/wiki)
• there is no EOL date for 2.10 although it is a known information (should be 2021-06-15 according to https://github.com/cakephp/cakephp/wiki)

[marcwrobel]

First PR that fixes product releases : #2271.

[marcwrobel]

All changes except the removal of the minor versions has been moved to #2289, #2290 and #2291.

[marcwrobel]

Closing this: all PR has been merged and there seems to be no further issue to discuss.