jsFiddle for Oracle JET 2.0.1

Last month I put together an Oracle JET "base" jsFiddle using Oracle JET 2.0.0 (files served through the RawGit CDN). I naively believed I could just keep that base jsFiddle current and all forks would continue using older versions of Oracle JET. When Oracle JET 2.0.1 released, I tried to update that base jsFiddle and realized it was already current. Since RawGit pulls directly from GitHub (sort of; I'll explain later), no updates were necessary. My first thought was, "Wow, that is great!" My second thought was a bit terrifying, "What if a future Oracle JET release has different dependencies?" Every fiddle forked from that initial base fiddle would break. At that moment I realized I would have to version my Oracle JET base jsFiddle. Since the original was built on Oracle JET 2.0.0, I appropriately renamed it Oracle JET Base 2.0.0. If you review that jsFiddle, you will notice it now contains the release's commit hash, 49fcbbde7c8e178a3a21625d44485536e3ad1aaf, in URL's.

I just forked 2.0.0 into Oracle JET 2.0.1 and pointed the URLs at the 2.0.1 release commit. I recommend forking this new jsFiddle until the next Oracle JET release. Fortunately, the external dependencies (knockout, jQuery, etc) were the same between these 2.0.0 and 2.0.1, but don't count on that for future releases.

Why did I include source, unminified files in these jsFiddles? These jsFiddles are designed for testing, prototyping, debugging, and sharing. When asking for help in the Oracle JET OTN Forum, it is really helpful to use debug rather than minified files.

What about that RawGit CDN? RawGit serves raw GitHub content. While the content may be the same as appending ?raw=true, the delivery mechanism is different. URLs served from cdn.rawgit.com are actually served through MaxCDN's network. Files are permanently cached so requests don't actually travel back to a git repo. Because of the longevity of the word permanent, the RawGit FAQ encourages the use of commit hashes to ensure serving the correct version. This is why I said earlier that "RawGit pulls directly from GitHub... sort of," and another good reason to reference the commit hash in URLs.