No longer publish new releases for Bower and Git submodules #1677
Comments
Krinkle
added a commit
that referenced
this issue
Jun 12, 2024
For QUnit 1.x and QUnit 2.x, we supported use of QUnit via Git submodules, where we put the Git tag on a commit that isn't in the main line, but instead a detached commit that contains the release artefacts. This is also what Bower built on top of. These two distribution methods will continue to work for old releases, but QUnit 3.0 will instead only be canonically published to code.jquery.com from where it can be downloaded over HTTP and HTTPS (for setups that prefer something simpler than npm). This means we don't need a separate "prepare" and "release" commit, so merge these steps into one, and place the tag on the main branch commit instead. This also means we need to do our version field differently. We can: * Keep "-pre" in Git, but have the release step temporarily remove it without including in the tagged commit. * Change proper version for the release commit, then push another commit that changes it back. * Use the proper version always, and let the build step inject "-dev" for non-release builds. I went with the third option, which seems most conventional in the JS ecosystem these days to simply leave it at the last release number between releases. Ref #1677.
Krinkle
added a commit
that referenced
this issue
Jun 12, 2024
For QUnit 1.x and QUnit 2.x, we supported use of QUnit via Git submodules, where we put the Git tag on a commit that isn't in the main line, but instead a detached commit that contains the release artefacts. This is also what Bower built on top of. These two distribution methods will continue to work for old releases, but QUnit 3.0 will instead only be canonically published to code.jquery.com from where it can be downloaded over HTTP and HTTPS (for setups that prefer something simpler than npm). This means we don't need a separate "prepare" and "release" commit, so merge these steps into one, and place the tag on the main branch commit instead. This also means we need to do our version field differently. We can: * Keep "-pre" in Git, but have the release step temporarily remove it without including in the tagged commit. * Change proper version for the release commit, then push another commit that changes it back. * Use the proper version always, and let the build step inject "-dev" for non-release builds. I went with the third option, which seems most conventional in the JS ecosystem these days to simply leave it at the last release number between releases. Ref #1677.
Krinkle
added a commit
that referenced
this issue
Jun 12, 2024
For QUnit 1.x and QUnit 2.x, we supported use of QUnit via Git submodules, where we put the Git tag on a commit that isn't in the main line, but instead a detached commit that contains the release artefacts. This is also what Bower built on top of. These two distribution methods will continue to work for old releases, but QUnit 3.0 will instead only be canonically published to code.jquery.com from where it can be downloaded over HTTP and HTTPS (for setups that prefer something simpler than npm). This means we don't need a separate "prepare" and "release" commit, so merge these steps into one, and place the tag on the main branch commit instead. This also means we need to do our version field differently. We can: * Keep "-pre" in Git, but have the release step temporarily remove it without including in the tagged commit. * Change proper version for the release commit, then push another commit that changes it back. * Use the proper version always, and let the build step inject "-dev" for non-release builds. I went with the third option, which seems most conventional in the JS ecosystem these days to simply leave it at the last release number between releases. Ref #1677.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We currently commit the distribution files to the tagged release commit (example). To reduce noise in the main branch, this commit is detached from it. This in turn means that native Git tooling doesn't understand version attribution well, which affects contribution and maintenance workflows. It's also one of the more manual parts of the release process.
So much for cost. What about the value proposition, and thus their original justification:
Removal of this was originally proposed for QUnit 2.0 in 2016, but at the time we forgot to follow through. I'm proposing to do this for QUnit 3.0 later this year.
The recommendation for affected developers and their projects, would be to either check in a copy of the file as offered from the CDN (see release channels), or to use npm. Given the more stable and sustainable/low-tech nature of projects that tend to opt for Git sumodules, I imagine checking in qunit.js will be the smoothest option to choose. Although if projects already require use of Node.js, and have an npm-based workflow in-place, and don't support running any tests without it, then that would a viable option as well.
More details and background at #1133 (comment).
See also https://bower.io/blog/2017/how-to-drop-bower-support/.
Ref bower/bower#2482.
The text was updated successfully, but these errors were encountered: