Goal: Identify unmaintained sling modules and mark them accordingly (by moving them into attic), so it's clearer which modules require active maintenance (e.g. for example deactivate the renovate-bot for all modules in attic and reduce noise).
Approach: Use the last commit into the src directory as initial criteria to come up with a list of candidates, then refine it.
- Actively used modules (for which no change was required in the last years) will remain active (e.g. they are referenced by other Sling modules)
- Modules for which a committer or community member shows interest will remain active.
- We will start with the deprecation where we have only votes favoring deprecation.
(Note: The decision to move a module into attic can be reversed at any time, if the necessity arises.)deprecate a module does not mean that this decision cannot be undone.)
See also: https://sling.apache.org/documentation/development/deprecating-sling-modules.html
General notes:
- Bertrand Delacretaz https://sling.apache.org/documentation/development/deprecating-sling-modules.html is our standard way of deprecating modules, I'm not sure what "moving to attic" means besides that. If this process needs to be adapted for this cleanup, that page should be updated.
- Joerg Hoh valid point, I changed the phrasing.
- Bertrand Delacretaz I think any module that's still actively used should remain active, I have noted a few of them below but there's more, I'm pretty sure discovery-api and jcr-api for example are in active use. The fact that they do not need changes does not matter IMO when it comes to keeping them active.
Data extracted via: find ./* -maxdepth 0 -type d | while read a; do (cd $a; test -d src && echo -n "$a," && git log --date=format:%Y -1 -- src -- | grep Date); done | grep 201 | sort -t ' ' -k 2 -n
...