Add slicer to endoflife.date website?

Overview

The website is a useful resource to find out which version is current, actively maintained, receiving security patches, …

Here are few examples:

Slicer release cycles, list, …

We could basically transition the information of these pages into something more formal:

The idea could be to :

  • have an authoritative document [1] listing all releases hosted on our GitHub repository
  • render it on our website similarly to what is done one the endoflife website by levering the relevant template [2]

or we could simply redirect to the endoflife and just have a PR automatically created against https://github.com/endoflife-date/endoflife.date when we modify our version.

Reading this is also informative: Recommendations for maintainers | endoflife.date

Question(s)

Would that be helpful ?

Any other suggestions ?


[1]: For example, it could be stored like as a markdown like blender.md
[2]: https://github.com/endoflife-date/endoflife.date/blob/master/_layouts/post.html

The endoflife sites are nice easy to read websites if there are going to be multiple minor versions of Slicer supported at any given time. Does Slicer plan to start supporting multiple minor released versions? As far as I have observed there has typically only been 1 stable version and then the preview release. If there is a bug or minor improvement it has gone into the preview release and there really hasn’t been backporting of items to continue support for a released version. I believe version 4.10.2 was still fairly similar to the main master branch at the time of its release.

It would seem the multiple supported versions would increase maintenance duties if there is someone who has the time to cut more frequent patch releases to truly continue support for multiple versions. Using endoflife you would specify at time of a new release when it go endoflife, so you would need to keep official support for that version during that entire time and also have its replacement released by then. The dates could be changed, but that should probably be avoided if possible.

As it relates to documentation of release date, release notes, announcements, etc that would all be good to have in the GitHub Releases area. I typically check dates of tags/releases and look for changes in that area for other projects.

+1 for a clearer support policy for slicer releases to make things transparent for users but also for extension developers/users. I agree we should try to keep things simple, and to be realistic somewhat flexible given that we don’t have a lot of dedicated resources.

I agree that we should document more clearly what Slicer releases are supported. The GitHub wiki could be a good place for it.

Contents of Release Details - Slicer Wiki and Documentation - Slicer Wiki pages could be moved to GitHub releases.

The https://endoflife.date/ website contains a tiny collection of about 90 projects (just in comparison, there are 28 million public projects on GitHub). The selection seems completely random - operating systems, applications, frameworks, libraries and not comprehensive or organized in any way. I don’t think we are missing out on anything by not listing Slicer there.