You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the README file, we state that we also maintain downwards compatibility:
Branch 4.x with maximum compatibility to Python versions 2.7 and 3.4+, PyPy2 and PyPy3.
It is not actually true from my perspective: We have not received one PR with a fix to that branch. There were PRs that could have been applied to master and to 4.x, too but nobody did it. There is no update except from tests since we took up maintenance again.
So, it would be right from my perspective, to drop the claim.
Here is my proposal:
To take Plone as example: Plone 6.0 is where all the current action is, and 5.2 is in maintenance mode. If a fix is done in 6.0 and it makes sense to apply the same fix in 5.2, then this is possible, but it requires someone to do it. Usually the original creator of a fix does this, sometimes of their own free will, or because someone explicitly asks them. Sometimes another person does this. If it is an obvious fix and it takes less than five minutes to back port it and do a quick check, then it often happens. But often enough, it is not so simple, and it just does not happen.
If we approach this slowly: Our last Py2.7 release was 2023-09-06. Releases to that branch were made once a year. We might not have a contribution to that branch until 2025. in At the moment and more so in 2025, a lot of software has already migrated from 2.7. 2.7 is end of life. I start to think, it is fair to remove the 4.x mentions in the documentation and just focus on the master branch. If anyone has objections, they can voice them!
In the README file, we state that we also maintain downwards compatibility:
It is not actually true from my perspective: We have not received one PR with a fix to that branch. There were PRs that could have been applied to master and to 4.x, too but nobody did it. There is no update except from tests since we took up maintenance again.
So, it would be right from my perspective, to drop the claim.
Here is my proposal:
Since we pour more effort into maintaining and developing icalendar, we decided on this structure:
What are your thoughts on this?
The text was updated successfully, but these errors were encountered: