Add a CHANGELOG.

[wearhere]

As we're about to mark 1.1, time to start actually tracking our changes. 1.1's going to be a bit of a doozy to start out--we shouldn't overwhelm the reader, yet convey a sense of how much we've added/fixed since 1.0.1, if possible.

[MaxGabriel]

Hey Jeff, do you think this is something I'd be able to do? I think I'd just need to know what format to use (I kind of like Cocoapods' myself) and a rough idea of how detailed you want to be for the 1.1 release.

[wearhere]

You're very much welcome to take it on, thanks! I think following Cocoapods' model is a great idea--there's a lot of nice touches to that like the installation link at top; the compare links; and certainly crediting the contributors responsible.

Re: detail I think I'd like to describe all the enhancements, and major bug fixes (think "holy shit I can't believe that was broken to begin with" haha, like device support). I'd definitely leave "tech debt" stuff out except for stability improvements.

I don't think there are any breaking changes for this release (hence it being 1.1). #143 will require Xcode 5.1--which will be good to note in the CHANGELOG--but it supports iOS 5.1 if you run Mountain Lion and manually install the iOS 5.1 simulator.

[MaxGabriel]

Working document of what git commits to be included in 1.1: https://gist.github.com/MaxGabriel/10001735

(You probably don't want to read this btw—the formatting makes it almost impossible to read and its probably better to wait for the finished changelog and then add stuff from that point).

General methodology:

Document in the 1.1 changelog:

• Public API additions
  • New SLElement subclasses, the method to double tap an element, etc.
• Notable features (pretty-printing CI output, Cocoapods support)
• Deprecations
  • Only deprecation I think was removing the PRODUCT_NAME and INFO_PLIST attributes from the install instructions, but its not a breaking change, so I might not need it

Don't document in the 1.1 changelog:

• Subliminal itself related changes ('fixing the build', 'setting up Travis CI', etc)
• Internal changes/refactoring
• README changes

(This methodology is specific to 1.1 b/c it has a ton of commits. 1.1.1 or whatever can be more thorough).

[MaxGabriel]

This can be closed—forgot to include this issue in the Changelog PR commit messages to close this one.

[wearhere]

Oh yeah, thanks.