>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3542597. --> Reported by: [hosterholz](https://www.drupal.org/user/3652307) Related to !37 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>When updating scheduled_publish but not drupal/core, the JavaScript cache-busting parameter remains the same (e.g. ?v=10.4.8). When updating drupal/core but not scheduled_publish, the JavaScript cache-busting parameter changes.<br> <a href="https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php?ref_type=heads#L169">LibraryDiscoveryParser</a> applies the Drupal version to every library that uses <code>version: VERSION</code>. It does not use the modules version.</p> <p>See the note on <a href="https://www.drupal.org/docs/develop/creating-modules/adding-assets-css-js-to-a-drupal-module-via-librariesyml">Adding assets (CSS, JS) to a Drupal module via *.libraries.yml</a>:</p> <blockquote><p>Starting from Drupal 10.1.2, the version information within a library definition plays a critical role in generating a unique hash for aggregated files. Consequently, it is imperative that the "version" in a library definition is updated whenever a referenced CSS/JS file undergoes changes.</p> <p>Alternatively, <strong>if the version is omitted, the prior behavior will apply, where the content of referenced CSS/JS files is utilized in the hash.</strong></p> <p><strong>Incorrect usage of version information could lead to browser and edge cache invalidation issues.</strong></p> <p>See <a href="https://www.drupal.org/node/3301716/revisions/view/12744806/13230795">this update</a> on the <a href="https://www.drupal.org/node/3301716">related changelog</a>. </p></blockquote> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Remove <code>version: VERSION</code> from scheduled_publish.libraries.yml</p>