search

twolfson / google-music.js

Browser-side JS library for controlling Google Music
The Unlicense
47 stars 6 forks source link

Add hosted floating major/minor releases #22

Open twolfson opened 8 years ago

twolfson commented 8 years ago

As initially proposed by @MarshallOfSound in #13, it would be useful to have a hosted floating "3.x.x" version of google-music.js. Here are some excerpts from the thread and the general flow of the conversation:

@MarshallOfSound - https://github.com/twolfson/google-music.js/issues/13#issue-121888040

c) These fixes still relied on the user updating their application, if for whatever reason they decided not too (some users are stubborn like that) they will not get the fixes... [...] Instead of depending upon statically released JS files we should depend on a CDN? Or the latest github release? so that updates to this framework, can be pushed independently of a version bump on our players

@twolfson - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164205247

While I understand your concern, I think this is attempting to solve an effect of a deeper problem. There's usually a reason for people refusing to update (e.g. nothing telling them about new update, not willing to take time to update). For that, I would suggest finding out why and maybe adopting an auto-updater (e.g. Squirrel -- what's used by Electron):

https://github.com/Squirrel

Additionally, if we were to always point our JS to master, then it will only work until we introducing a breaking change. At some point, our API might change; we might rename a method or change a function signature for ease of use or consistency. We don't want to code ourselves into a corner which will break everyone =/

One alternative would be to have major/minor branches as part of updates (e.g. for a release like 1.2.3, we would update a branch 1.x.x and 1.2.x which point to the same version). That could be used with http://rawgit.com/. I use the same technique on gratipay-badge:

https://github.com/gratipay/gratipay-badge

@jacobwgillespie - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164209675

I like the idea of having proper semver and publishing 1.x, 2.x versions that are live-loaded over HTTPS, since then we can push fixes while not breaking backwards compatibility. Eventually we'd stop pushing fixes to older branches, so at some point users would need to update their apps, and for that I like the emphasis on each individual app implementing an easy / auto updating system.

@chrismou - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164209877

App updates are probably something that should be left to the individual app. Radiant I think uses the sparkle framework, which is pretty seamless. I doubt we'll want to move away from that any time soon.

@MarshallOfSound - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164218961

I don't think I was quite clear on what I meant about independent releases in my original post :disappointed: But it appears as though you picked up on more or less what I was hoping for anyway :grinning:

Basically the branch idea that @jacobwgillespie talks about it what I would be after, being able to load in the latest dist file from a 3.X.X branch that was tagged with stable for instance would be the perfect workflow for me.

What version and how you fetch it would be entirely up the app though, you might decide to push out static files with each release, or to live on the wild side and fetch straight from master (plz no)....

@twolfson - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164306604

@twolfson - https://github.com/twolfson/google-music.js/issues/13#issuecomment-164314110

Damn, hit a snag with rawgit.com. I could have sworn that the cache eventually expired but it turns out it doesn't:

http://rawgit.com/faq#cdn-ttl

I'm sure that if we use the non-CDN version, then we will eventually have too many users and piss people off. There are options like S3 and such but I feel like we are starting to make a mountain out of a molehill =/

Then, the thread goes into a discussion of finding gitcdn.xyz and jsDelivr and their comparisons:

https://github.com/twolfson/google-music.js/issues/13#issuecomment-164314360

We are still on the fence about one over the other: