Use separate tag for NPM dependency resolution #408
Conversation
In #366, we centralized the process for managing NPM dependencies, replacing the decentralized approach. While this change is transparent for most projects, it introduces a chicken-and-egg problem when releasing `logging-parent`: * The website build fetches NPM dependency versions from the GitHub repository based on a specific tag, currently `rel/<version_number>`. * However, for `logging-parent`, the `rel/<version_number>` tag can only be created *after* the release is validated—which requires building the website. To resolve this, we propose using a mutable tag: `site-deps/<version_number>`. This tag will initially point to the commit preceding the release and allow the website build to proceed. Once the release is finalized and the `rel/<version_number>` tag is available, `site-deps/<version_number>` will be updated to match it. ### Security considerations I am not a big fan of using mutable tags. However, previously we had no control on which NPM package versions are used to build the website. Now we lock those dependencies, but we cannot lock the release tag.
|
@ppkarwasz, I am very much favor of reverting #366 instead, which has the following motivation:
I read this as "good to have, but nothing critical". We increased complexity in #366, now we will even increase it more because #366 broke something. This adds two more extra steps to the release process – you know my stance on this: don't! As I shared with you in private, I am very concerned about the recent "good-to-have, yet not really needed" features. Log4j doesn't have full-time employed maintainers. Increasing complexity without solid justification will only make the life of existing maintainers more difficult. I suggest reverting #367 (implementing #366) and closing this PR. |
|
Good point! 💯 I must admit that the proposed solution adds unnecessary complexity to the release process. As you suggested, I am closing this and reverting #367 in #409. That PR also improves the caching behavior for Node.js modules that currently does not work as expected and commits |
2 participants
In #366, we centralized the process for managing NPM dependencies, replacing the decentralized approach. While this change is transparent for most projects, it introduces a chicken-and-egg problem when releasing
logging-parent:rel/<version_number>.logging-parent, therel/<version_number>tag can only be created after the release is validated—which requires building the website.To resolve this, we propose using a mutable tag:
site-deps/<version_number>. This tag will initially point to the commit preceding the release and allow the website build to proceed. Once the release is finalized and therel/<version_number>tag is available,site-deps/<version_number>will be updated to match it.Security considerations
I am not a big fan of using mutable tags.
However, previously we had no control on which NPM package versions are used to build the website. Now we lock those dependencies, but we cannot lock the release tag.