Friday, September 28, 2012

News: ember-latest.js Updated (and Understanding GitHub Downloads)

Note: Today's scheduled post "Ember.js Debugging 1 — Firefox" is postponed until tomorrow so I can cover this today instead.

I just happened to notice earlier today that the ember-latest.js download was updated last night. It's lucky I did, because apparently new/updated downloads do not appear in my GitHub notifications, even though I'm following the repo.

This sent me on a sub-journey of GitHub discovery and exploration, which I'd like to share with you.

GitHub Downloads


It turns out there's scant information out there about the downloads feature. The only reference I could find was in the API docs, which cover the basic CRUD operations of retrieving the list of downloads (which you can see here), creating new downloads, and deleting downloads (the last two are for repo admins, obviously).

Downloads exist outside the repo itself. They are not part of the codebase, they are not versioned by git, they are not found in the tarball. They are uploaded directly to Amazon S3 by a repo admin. If a new version of the same file is uploaded, there's no way to get the old version, or even a history.

While new/updated downloads don't appear in the notification stream, they do appear in the event stream as type DownloadEvent — which happens to be what the wonderful Ember.js Dashboard site pulls from, so they'll appear there... briefly (it only pulls the most recent 30 events).

Note: Every time I visit the events API in Firefox, it redirects me to the developer docs. I can't figure out why, the activity isn't showing up at all in Firefox's Web Console or Firebug's Net tab, and it works just fine with both Chrome and curl. Infuriatingly unexplainable. PS-I'll be covering Firebug on Sunday.

GitHub Feature Requests

If anyone from GitHub is reading this...

  • Please have download events show up in the notification stream when you follow a repository. It usually signifies a new version being released, which is about the single most significant event that happens for a repo.
  • Please add the ability to view the history for a download so that in the case of something like ember-latest.js, which periodically gets re-built, the past doesn't fall down the memory hole.

Now, About ember-latest.js...

I thought it was important to publish this post ASAP because I'll be using ember-latest.js in this blog, and you'll likely be using it in your apps. We need to be aware of the fact that it could change any second and immediately begin affecting us, and how to learn more about that.

I don't know if there's a schedule or other criteria as to when/why ember-latest.js gets updated. There's no history available for me to deduce that from, and my brief asking around about it hasn't paid off yet.

Versioning

Let's poke inside. If you grab ember-1.0.pre (which is the latest tagged version and hence the closest thing we have to a "stable" version until 1.0 is released), you'll see these two lines at the top:
// Version: v1.0.pre
// Last commit: 7955b85 (2012-08-03 14:50:17 -0700)
A simple version number, an abbreviated reference to the commit that was tagged for this version, and the date of the commit (which is the same date the download was created, though I imagine that's not always true if the admins don't go upload the new build right away).

I managed to find someone with a copy of the previous version of ember-latest.js (before it was updated yesterday), which contains the following:
// Version: v1.0.pre-149-g117655b
// Last commit: 117655b (2012-09-18 10:22:34 -0700)
This version number is more complex. These versions do not get tagged as a version release; they are oft-iterated build versions. I don't know if it follows any kind of standard (like a "build" version of SemVer?). I'd guess the '149' is simply incremented each time they do a build, even if it's not released as a download, and the 'g117655b' is obviously a reference to the commit SHA.

Finally, here's the comment from yesterday's new ember-latest.js:
// Version: v1.0.pre-160-g7d62790
// Last commit: 7d62790 (2012-09-26 15:59:36 -0700)
So What's Changed?

I won't be covering what's changed since the last version of ember-latest.js right now... to be honest, I'm still confused and intimidated by the code. However, since all of my future posts will be written for and tested against ember-latest.js, what I do cover will include some of those changes. I'll try to point out when something I'm using has changed recently whenever I notice it.

You can get a glimpse at a subset of those changes at Bradley Priest's Weekly Ember Wrapup #15. Since the previous version of ember-latest.js was released on Sept 18, and Wrapup #15 was published on Sept 24, it covers some of what's new. I'm sure #16 will include more.

Next up: Debugging Ember.js with Firefox



Update: Got an email back from Kristofor Selden (the creator of the recent ember-latest.js) about the reason for releasing a new build:
"I updated ember-latest.js because the CP setter improvements in the last build had a bug that was fix in the commits on Sept 26.  Looking at the tests from those commits and the cp setter improvement commit should give you an idea."
I decided now's a good time to figure out a convenient way of using GitHub to produce a diff between two versions (identified by commit SHAs), and found this explanation of the GitHub Compare feature. Just append /compare to a repository URL and you'll be prompted to supply the starting point of the diff. I used 117655b (the SHA from build 149), then clicked on the gray label representing the end point and changed it to 7d62790 (the SHA from build 160). The start/end labels look like this:


The resulting URL:
https://github.com/emberjs/ember.js/compare/117655b...7d62790
Awesome. To quote the GitHub blog post:
"The Compare View brings all information needed to determine what changed over a series of commits onto a single page: a condensed commit list in chronological order, followed by a rollup diff of all changes between the two points, followed by any relevant commit comments. All in the same place and with a single well-defined URL."

No comments:

Post a Comment