Changelog

[ocombe]

Don't you think it would be nice to have a changelog to list the changes between the versions ?
Or at least document each release with a list of the changes.
Maybe the versions are released too fast at the moment, but it would be nice to have it at some point.

[zackbrown]

Great idea. Can you think of any ways to make this semi-automated? Maybe involving git log --pretty=oneline 0.0.11...0.0.12?

For version-bumping, the process of updating bower.json in the submodules, updating bower.json and package.json in the main project, building the docs, building the project, and tagging everything would be really nice to automate somehow, too.

And as things change, it would be nice to have the versioned docs working (I believe the version dropdown is just commented out for now in the doc templates)

Do you have any ideas for this stuff @ocombe?

[ocombe]

We could automate the thing but you would have to either do better commits messages, or take a look at the changelog to clean it before you commit.
For example here are the messages from 0.0.11 to head:

• update build
• version bump
• update submodule shas
• update docs
• support transitionables, handle faTransform override, clean-up
• update docs
• update build
• refactor fa-modifier transforms to follow model; abstract out logic to more easily support additional fields; add fa-transform-order attribute to support arbitrary transform restrictions + ordering
• start abstracting + refactoring fa-modifier getTransform
• refactor size and origin to the parse approach, also to support normal data-binding. update build
• update git urls in package.json
• update build
• handle functions with align; refactor opacity to use
• add fa-align support to fa-modifier
• Updated version number
• Removed unexistent "gulp dev-site" task reference
  update docs build
• update docs build
• Adds missing backticks so tags render in docs.
• Clean up faApp spec typos.
• Create spy for faAppSpec's registerChild test.
• update build
• Test that faSurface creates an instance of a Famo.us surface.
• Test that faSurface sets the content of its created Surface.
• Finish basic faSurface spec.
• Add fa-size test to faSurface spec.
• Set up background-color test for faSurface.
• add resumeBootstrap check to avoid testing exception; fix typo
• update build
• re-add '$'
• Remove old modifier code from fa-surface.js.
• Revert changes that were done to famo.us for testability. Convert tabs to spaces.
• Use Olivier's suggestion and update karma.conf to load famous core modules through a CDN, rather than bower.
• Since we're not loading individual requirejs modules, we don't need a
  requirejs config, so get rid of test-main.js.
• faApp test now properly triggers 'registerChild' event.
• Create basic faApp spec.
• Create faSurface spec.
• Finish basic famousDecorator Spec.
• Fixed famousProvider#registerModule not showing up in the generated
  docs.
• Add documentation for famousDecorator.
• Add delay for Karma's watch and auto-test, so that the gulp build task has time to finish.
• Add famousDecoratorSpec.js
• Remove out-of-date karma-e2e config.
• Remove site-related tasks from gulpfile.
• Add build task to gulp dev, so that when src is changed, dist is recreated as well.
• Update famousSpec.
• Remove jquery and underscore dependency from karma.conf.
• Clean up initial tests.
• Add the compiled source for the famous.js changes.
• Add check for defined angular.resumeBootstrap in famous.js.
• Add test for provider.
• Emit '' event once requirejs has loaded all famo.us scripts and has declared .
• Basic unit testing set up complete.
• Set up karma to serve files correctly.
• Create fresh test set up.
• Quick fix for 2 underscore functions I missed last time

As you can see, it's almost good but a bit of cleaning would be nice.
It would also be better to separate the new features from the bug fixes. Either manually, or by adding a "fix" tag at the beginning or each fix commit for example.

We could follow the conventions of the angularJS team: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

Format of the commit message
`():

`

We could then use this node module: https://github.com/ariatemplates/git-release-notes to generate a nice and clean changelog.

[zackbrown]

Great idea to go with the AngularJS conventions. Those guys have put some thought into their workflow :)

<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> feels a little heavy-handed for the current size of this project (complex contribution requirements could deter would-be contributors for small fixes.) How about starting with something like:

<type>: <subject> <BLANK LINE> <optional message>

Would it be easy to adapt Angular's command git-release-notes -t "^(\w*)(?:\(([\w\$\.]*)\))?\: (.*)$" -m type -m scope -m title v1.1.2..v1.1.3 markdown to fit that template?

I can introduce git rebase -i to my personal workflow on this project and we can encourage the same for other submissions/PRs.

Does this change log project sound interesting to you? You could make a sample well-formed commit along with the creation of the tooling, plus simple documentation for 'how to contribute,' then we can adopt it into the main workflow from there.

[ocombe]

Yes that would be nice. I agree that we could skip the scope/body/footer.
I'll get right on it.
I will also start making a gulp release task that will ask for the new version number (interactively), build everything (dist/docs), updates the package.json/bower.json files, and make the changelog.