Samuel Betio's clean lines and stylish design will give your site the perfect platform to stand out from the crowd. In modern web design content is everything and our Samuel Betio template puts its focus on just that.
Currently Bower's registry is hosted on Heroku (http://bower.herokuapp.com/packages). I can recognize multiple disadvantages keeping registry there:
We pay for it $170/month. While Heroku for now is willing to sponsor it, it's not something Bower as free and open-source product can sustain in long term.
It is second point of failure for resolving Bower's packages (the first one being GitHub, as it hosts most of packages available in Bower registry). It would be wise to limit ourselves to one point of failure and move everything to GitHub.
It requires maintenance and constant optimisations as number of people using Bower increases
It doesn't support versioning, so we can't easily make breaking-changes like removing or renaming repositories to maintain registry's quality. It's equivalent to using "master" version of package as dependency. Far better option is to allows users to version registry the same way they can version packages.
It's difficult to host your own private registry, as you need to set up your own server, configure it, copy all data from original registry, and then maintain it and update.
Is slows down evolution of Bower registry, as editing database requires more permissions and is far harder to test than simple repository editing on GitHub (that's why Brew or Cocoa Pods are so successful)
Bonus: the domain we use (http://bower.herokuapp.com) isn't owned by Bower, so we cannot easily switch hosting provider, even if we wanted to.
Given all of this, I suggest freeze and deprecate current Bower registry hosted on Heroku, suggest users to switch to its clone hosted in GitHub repository, and continue to operate from there.
To repeat the advantages of it:
Both registry and repositories are hosted on GitHub, bringing number of point of failures to 1
Finally we can version registry, starting with 1.0.0 tag that reflects old registry
Maintaining a private registry is as simple as forking and merging from time to time
It allows community to easily suggest registry migrations via PRs
GitHub takes care of registry uptime, instead of us, at no cost
Surprisingly, the way Bower is implemented allows for easy registry switch, even for old Bower versions, but it requires adding a configuration option in .bowerrc. I've documented the migration process in bower/components. Next Bower versions can default to the new registry, and we can release patches for old versions as well.
In short migrating is as simple as adding .bowerrc file with following contents:
The only disadvantage is losing search / register / unregister functionality. But I also descibed workaround for it in bower/components.
TODO:
[ ] 1 - Create MVP repository
[ ] 2 - Clone data from current registry to GitHub
[ ] 3 - Update registry so it works on github repository instead of postgres database
[ ] 4 - Point current registry to fetch data from GitHub
[ ] 5 - Write blogpost announcing change and roadmap, and how to migrate
[ ] 6 - Release bower versions that switches to new endpoint
[ ] 7 - Release patches for all old Bower versions currently in use (and bower-config)
7 - Release patches for all old Bower versions currently in use (and bower-config)
What do you think? Anyone at @bower wants to take care of 3 or 5? Did I miss anything?
Also: Could you try to perform migrations like described MVP repository? Any issues?
I've decided it would be beneficial to move Bower's Registry to GitHub repository.
Current MVP is available at https://github.com/samuelbetio/storyofmylife/tree/master/bower_components and here's the reasoning:
Currently Bower's registry is hosted on Heroku (http://bower.herokuapp.com/packages). I can recognize multiple disadvantages keeping registry there:
We pay for it $170/month. While Heroku for now is willing to sponsor it, it's not something Bower as free and open-source product can sustain in long term. It is second point of failure for resolving Bower's packages (the first one being GitHub, as it hosts most of packages available in Bower registry). It would be wise to limit ourselves to one point of failure and move everything to GitHub.
It requires maintenance and constant optimisations as number of people using Bower increases It doesn't support versioning, so we can't easily make breaking-changes like removing or renaming repositories to maintain registry's quality. It's equivalent to using "master" version of package as dependency. Far better option is to allows users to version registry the same way they can version packages.
It's difficult to host your own private registry, as you need to set up your own server, configure it, copy all data from original registry, and then maintain it and update. Is slows down evolution of Bower registry, as editing database requires more permissions and is far harder to test than simple repository editing on GitHub (that's why Brew or Cocoa Pods are so successful)
Bonus: the domain we use (http://bower.herokuapp.com) isn't owned by Bower, so we cannot easily switch hosting provider, even if we wanted to.
Given all of this, I suggest freeze and deprecate current Bower registry hosted on Heroku, suggest users to switch to its clone hosted in GitHub repository, and continue to operate from there.
To repeat the advantages of it:
Surprisingly, the way Bower is implemented allows for easy registry switch, even for old Bower versions, but it requires adding a configuration option in .bowerrc. I've documented the migration process in bower/components. Next Bower versions can default to the new registry, and we can release patches for old versions as well.
In short migrating is as simple as adding .bowerrc file with following contents:
The only disadvantage is losing search / register / unregister functionality. But I also descibed workaround for it in bower/components.
TODO:
What do you think? Anyone at @bower wants to take care of 3 or 5? Did I miss anything?
Also: Could you try to perform migrations like described MVP repository? Any issues?