Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to drop Bower support in version update #2482

Closed
ScottFreeCode opened this issue Sep 29, 2017 · 10 comments
Closed

How to drop Bower support in version update #2482

ScottFreeCode opened this issue Sep 29, 2017 · 10 comments

Comments

@ScottFreeCode
Copy link

The Mocha team would like to drop Bower support in a new semver-major version. Is it possible to do so without removing earlier versions of Mocha from the Bower registry? Are there any recommended best-practices for doing so?

@sheerun
Copy link
Contributor

sheerun commented Sep 29, 2017

Ideally you'd create https://github.com/mochajs/bower-mocha as a fork of current one, change url in bower's registry to https://github.com/mochajs/bower-mocha and then remove bower from https://github.com/mochajs/mocha

Please remember to also copy all tags

@ScottFreeCode
Copy link
Author

Thanks!

We copied all the tags from mochajs/mocha to mochajs/bower-mocha -- is there anything else needed to have the repo ready (e.g should we have the same bower.json in the master branch)? I have to admit to not having familiarized myself with how Bower works, for better or for worse.

It also turns out that the current team doesn't have the credentials to register/update Bower; if it's not too much to ask, could you have it updated for us once/if the mochajs/bower-mocha repo is ready?

@sheerun
Copy link
Contributor

sheerun commented Sep 29, 2017

You not only need to clone tags, but also contents (i.e. make it the copy of original repo). Currently this repository seems empty. Any contributor of mochajs/mocha repository will be able to unregister it from Bower, and then the same person can re-register it under different url.

Also you need to remember that bower caches url it resolves.. So as soon as you remove bower.json from original repository, the installations will fail when users depend on "mocha": "master"; their installation will also fail if they have "mocha": "*", and you add new tag to the original repository (without bower.json). The solution is to ask them to run bower cache clean.. and use proper semver.

@sheerun
Copy link
Contributor

sheerun commented Sep 29, 2017

Also, if you don't care about users (and developer of other modules) who have "mocha": "master" or "mocha": "*" in their dependencies (honestly you have right to, as they should use something like "mocha": "^3.0", then you can skip changing anything in bower registry, as well as creating new repository: You can just remove bower.json from original repo and tag with with major version (4.0.0). Installations won't break for users who depend on previous versions of mocha. Bower should properly resolve to versions of mocha that have bower.json in them (and distribution files).

@sheerun
Copy link
Contributor

sheerun commented Sep 29, 2017

@ScottFreeCode I want to publish blogpost about this. Could you proofread it?

https://github.com/bower/bower.github.io/pull/292/files

@boneskull
Copy link

@sheerun I'll be taking care of this for now, it seems. I think what I'd like to do--instead of copying the repo, unregistering and reregistering--is just to remove bower.json when we tag v4.0.0.

At least, that's what I understand from your post and this issue. Please correct me if I'm wrong. 😄

@sheerun
Copy link
Contributor

sheerun commented Oct 1, 2017

That's correct

@sheerun
Copy link
Contributor

sheerun commented Oct 1, 2017

My full answer is in blogpost: https://bower.io/blog/2017/how-to-drop-bower-support/

@ScottFreeCode
Copy link
Author

👍 Thanks @boneskull for taking this on and @sheerun for walking us through it! Removing the files in a semver-major and making sure people aren't depending on "*" is definitely more straightforward than trying to clone the repo (and doesn't leave us with a seemingly unused old repo sitting in the GitHub org too).

@sheerun One other question occasioned by the blog post -- and sorry I'm late getting back on this -- on Libraries.io, I see there are also projects depending on latest instead of * or master; does that also need to be changed to prevent breakage from the semver-major drop?

@sheerun
Copy link
Contributor

sheerun commented Oct 3, 2017

@ScottFreeCode It seems "latest" is synonym for "*". I've updated the blogpost to account for it.

@sheerun sheerun closed this as completed Mar 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants