Better versioning for cache-control

[superpoincare]

As things are now, twemoji.min.js is cached for 30 days in browsers.

This means that if the user has the file cached in his/her browser, changes to twemoji.min.js will appear only after 30 days.

If some versioning is done in the URL, things will be better. So we might need an address such as:

//twemoji.maxcdn.com/2.1.0/twemoji.min.js

so that the address itself acts as a cache-buster.

[WebReflection]

AFAIK that's not the case. MaxCDN is synced with this repository and if there is a change it will be reflected there pretty quickly, as soon as all end points are updated, usually we talk about minutes, not even hours.

However, it is also possible for us to do an "emergency purge" in case it's really necessary.

Versioning so far worked by major release version only and it's fine because it doesn't break anything in terms of usage, it gradually update eventually modified pngs through an updated RegExp, which is the only thing that actually changes in the entire file.

As summary: if you want me to purge everything for some reason, but I see already the new version on MaxCDN without any issue, I could do that.

Adding a minor version with the current structure would complicate things for both this repo and MaxCDN current offer since the amount of duplicated assets won't be worth the trouble (IMO)

[superpoincare]

Yes I understand purging can be done. Cloudfront takes 15 minutes and I guess MaxCDN should be similar.

My issue was about the user browser cache. Suppose a visitor visits my site which is using twemoji. The cache headers ask the browser to set the max-age to 30 days. If the visitor visits the site in the next 30 days, he/she won't get the updated version of twemoji.min.js even if it is updated on Github and is synced with MaxCDN.

This is the reason Google's hosted libraries have rules with versions/cache.

[WebReflection]

I don't understand the problem. If you have to manually change your site url just use the following?

//twemoji.maxcdn.com/2/twemoji.min.js?2.1.0

What is the benefit of duplicating all assets by minor version on MaxCDN?

All icons that didn't change needs to be re-downloaded for no reason but all you want to do is have the latest version of the library with the latest RegExp ... right?

Since in order to do that you want to change your own url, you're free to do the same via basic query string info. At least assets that were already downloaded, will still be the same and only the script will change.

Having versioning as it is now for this repo structure, where v1 has also different assets and introducing minor versioning should also respect assets versioning for consistency sake, is in my opinion not needed and counter-efficient for users.

[superpoincare]

I agree that appending a query string will solve. But the problem is not just a personal one. It's about all users of twemoji.

Users are not going to pay that much attention to cache control and all that. They'll just copy paste the script src. And when they do, regular visitors to their websites won't be served the latest version immediately.

About assets ... you can still refer to the same assets with a different naming convention for twemoji.min.js. So that sort of question doesn't arise.

Naming files should always keep in mind cache busting.

[WebReflection]

I agree that appending a query string will solve. But the problem is not just a personal one. It's about all users of twemoji.

we don't control external websites that use twemoji. We cannot grant everyone will update the link accordingly. However, we can put on the README that the new link has a query string ... I still don't understand what's the problem in doing so.

Users are not going to pay that much attention to cache control and all that. They'll just copy paste the script src. And when they do, regular visitors to their websites won't be served the latest version immediately.

Your proposal doesn't solve this problem, do we agree on that?

About assets ... you can still refer to the same assets with a different naming convention for twemoji.min.js. So that sort of question doesn't arise.

for consistency sake, samever should grant samever. We don't follow samever here.
Some asset has been updated, people trusting previous image/icon via samever could be upset if suddenly the image changes (for whatever reason ... it's about respecting samever principle)

Naming files should always keep in mind cache busting.

I personally like KISS and YAGNI approaches which worked well 'till today since this repo was announced. I am not saying the current status is perfect, I am saying it just worked ¯\_(ツ)_/¯

[superpoincare]

"we don't control external websites that use twemoji. "

Precisely the issue. A coder has to understand things which can go wrong. The versioning could have been designed, or still can be designed keeping things like this in mind.

Have a look: http://www.paulirish.com/2009/caching-and-googles-ajax-libraries-api/

(the max-age numbers have probably changed but the idea is the same).

So a version like 2 should have low max-age. More specific ones higher. So 2.1.0 may have a high max-age.

[WebReflection]

Again, your proposed solution does not work. Developers have to come over and realize there is a new link to use and copy that.

Which is exactly what I am going to do now, updating the README so the problem will be solved:

• no need to change anything in MaxCDN since it's not even possible for us
• no need to duplicate assets to be consistent with samever
• whoever copy and paste the latest link will have the latest library

Deal? Because I'm pretty sure the folder is not going to happen, since it doesn't solve the problem and it doesn't keep things simple for both this repo and MaxCDN.

I hope this works.

[WebReflection]

Actually, to make it even simpler: we cannot technically configure MaxCDN to do what you are asking and this repository changes once every 6 months or something, which is when new emoji comes out.

We did a simple setup based on sync and that worked so far, we don't need samever because we won't have so many changes.

Even if users have to wait up to 30 days for some new assets I personally don't see this as a problem but if it is, then whenever there is a new version we'll keep the link updated so that everyone can check the latest is the used one.

[superpoincare]

You could drop the cache-buster query string and instead use max-age of 1 day and "stale-while-revalidate" for a month.

Google fonts does this.