>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3566867. --> Reported by: [feyp](https://www.drupal.org/user/998680) Related to !5 >>> <div class="note-warning"> <p>PatchInfo is now obsolete. Use <a href="https://packagist.org/packages/cweagans/composer-patches" rel="nofollow">cweagans/composer-patches</a> as a replacement.</p> </div> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>PatchInfo was a great module for Drupal 7. Most module updates would be done via UI back then and patches would be applied manually on the console. So when the developer was applying the patch, they were in the module's folder anyway and adding the patch entry to the .info file as in-code documentation of the patch was quickly done. When a user wanted to update a module via UI, PatchInfo would list the patches prominently to warn users that they might need to reapply the patches after the update. No need for creating and maintaining any external lists of patches somewhere else and checking it each time you wanted to update a module, it was all inside the Drupal installation, readily accessible for every developer working on the project with minimum extra time spent to add the needed documentation when applying a patch. All in all a very efficient way to keep track of your patches, significantly speeding up any module update process.</p> <p>For Drupal 8, the module was already needed less, but was still somewhat useful during the transition to fully composerized Drupal installations.</p> <p>Starting with Drupal 9, Drupal installations were usually fully composerized and any patches would usually be managed and applied using <code>cweagans/composer-patches</code>, which was also good for in-code documentation in a similar way to what PatchInfo provided. So at the EOL of Drupal 8, I already thought about not even porting the module to Drupal 9 and letting it die. There were still a few people, who told me they saw some merit in having a list of patches accessible from the UI, there were a bunch of users still using the module, and porting the module was not too much work, so I kept the module alive for Drupal 9 and Drupal 10 and even Drupal 11, even though it is less and less needed or useful nowadays.</p> <p>In the meantime, I do not have as much free time as I used to have, and there are a couple of imminent changes happening in the ecosystem that affect this module: it is currently not compatible with cweagans/composer-patches 2.0, drupal.org is migrating issues to GitLab, and the update module in core is going away eventually. Addressing all of these issues would require some significant work to keep the module running.</p> <p>At the same time, the module has become less useful as a tool for developers. Since 2.0 cweagans/composer-patches also allows to specify your own patch metadata and allows for easily writing your own plugins to extend it, so at least by now the package should work well as a suitable replacement for the module.</p> <p>Having considered all of this seriously, weighing the different options, I have decided that it would be best to focus the limited time I have for contributions somewhere else and finally mark this module as obsolete. I actually have some ideas how the module could be made more useful again, but that would also require some significant rewriting of the code, which I'm currently not in a position to do anytime soon. Maybe it will be possible to revive the project in the future, we'll see.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Mark PatchInfo as obsolete, pointing users to cweagans/composer-patches 2.0 as a replacement.</p>