Broad updates:

[ehelms]

See the commit notes for what the updates.

[ehelms]

As we discussed in #ui-alchemy, I'll look into a grunt task that might be able to automate the generation of a release branch to keep the release flat. There is still the question of keeping CSS and SCSS together or putting one or both into a directory within release.

[ehelms]

Tracking story and tasks - https://trello.com/card/rename-alchemy-to-alchemy-base/515464bf7c5419082f000f9d/32

[jcoufal]

+1 for flat structure.

CSS vs SCSS, I am for naming files:

• alchemy-base.css
• alchemy-base.css.scss

Which looks enough for their differentiation.

[ehelms]

@jcoufal I played with .css and .css.scss. When importing I had to specify it as:

@import 'alchemy-base/alchemy-base.css.scss';

[jcoufal]

@ehelms so we keep using *.css.scss and in import we need to specify the extension as well? Is it the conclusion?

[ehelms]

@jcoufal I played around with it, and if we stick with css and scss, compass will import the .scss file if you just specify 'alchemy-base'. I had to explicitly specify the .css extension anytime I wanted to import the .css file. And thus I think we should stick with .scss and *.css to avoid having to do `@import 'alchemy-base.css.scss'

[ehelms]

@waldenraines @jcoufal I have updated this PR to include a grunt task that attempts the following:

1. Checks if there is a tag that matches dist/component.json, if so, aborts, otherwise continues.
2. Deletes any local 'release' branch.
3. Uses git subtree to generate a new release branch based off of dist/
4. Checks out the release branch
5. Tags the release branch with the version specified in component.json
6. Attempts to push the release branch and tags to a remote named 'alchemy'

One question I was pondering was whether publishing the dist/ directory in master made sense, or if we should ignore the directory, and have the release task run a 'grunt build' and then a 'grunt release'. Developers would still be able to run 'grunt build' locally for testing, it just means we would only be checking in 'builds' when we did a 'release'.

[jcoufal]

@ehelms +1 for .css / .scss issue as long as it is not that much confusing for you. As for me it works.

[jcoufal]

@ehelms As long as we provide links for download separate components' .css or .js in magnum-opus website, it makes sense for me to exclude dist/ from component master repository and keep it as a place for development sources. For distribution we will use just alchemy one (but keep in mind to give user an option to download files related just to one component).

[jcoufal]

btw I like renaming app to demo, +1

[waldenraines]

@ehelms here's one release numbering process I've used in the past that I think works well.

Say your just released version is 0.0.1. As part of the release the script would change the version in component.json to 0.0.1-SNAPSHOT. Subsequent development would be done against the SNAPSHOT build and we could "release" (really just build, as you mention above) snapshot builds as well but they would obviously be less stable.

Then, once we're ready to bundle up some changes into a cohesive release, we would run the release task which would do all the tagging, etc. mentioned above as well as removing the -SNAPSHOT from the version and incrementing the version once released.

This may be overkill for alchemy but it keeps things nice and orderly and also distinguishes the snapshot (work in progress) builds from actual releases.

The dist directory in master could contain the current release snapshot builds for those who like to remain on the bleeding edge (and also QA). Or we could even actually release snapshot builds (git tag -f) builds and put them in bower if we wanted to.

[ehelms]

@waldenraines interesting idea, and might make the build and release process in terms of version bumps easier as well. One thing I had been pondering, but not expressed out loud was the idea of a 'devel' release on bower which would essentially point to master. I am not entirely sure if that would work, or just require some manipulation of the component.json or having two of them. But I do like the idea of bumping the version, marking it and then just removing the SNAPSHOT when releasing. I would think the release task might need a way to specify different version bump levels to handle the three digits (e.g. point-release, minor, major)

After walking away I realized, that the tags themselves with the way versions work with bower can handle all of that.

[waldenraines]

I'll go ahead and ACK this and we will make incremental improvements as we see fit.

[jcoufal]

+1 for @waldenraines's idea about snapshots +1 for @ehelms tripple digit way of numbering releases

[ehelms]

I have added updates to the release process task which include some updates to jshint based on previous conversations, renaming component.json to bower.json per Bower's documentation and moving bower.json to the top of the directory. Also, this adds a '-devel' flag for master bower.json. This process now:

1. Checks that a tag doesn't already exist for the current version.
2. Copies bower.json into memory.
3. Deletes local release branch.
4. Subtrees dist/ directory
5. Checksout the release branch.
6. Removes the '-devel' flag from the version, writes a bower.json and adds it to the branch.
7. Commits the bower.json to the release branch.
8. Tags the release branch with the version specified in bower.json

Potential other steps to add:

1. Checkout master
2. Update version in master within bower.json

[ehelms]

I added grunt-docular to this pull request, and documented the small bits of JS that are in this particular repository. This documentation is built similar to how the AngularJS documentation is built and allows for declaring factory/service/directive etc. You can view what it produces by checking this PR out and running:

grunt docular
grunt docular-server

[ehelms]

I was also looking into CSS documentation and came across these two:

• http://warpspire.com/posts/kss/
• http://jacobrask.github.io/styledocco/

[ehelms]

@waldenraines @jcoufal Please review my latest changes. I have changed the tactic to remove dist/ from git and provided a release task to account for that. Release workflow:

1. Fetch upstream tags
2. Check that the version in bower.json doesn't already contain a tag
3. Run 'grunt build'
4. Copy bower.json into build directory dist/
5. Checkout release branch
6. Copy contents of dist/ into top level of release branch
7. Add any new files to git
8. Commit files with an automatic commit message including the version
9. Tag the release branch at the version in bower.json

[waldenraines]

What do you mean when you say "Check that the version in bower.json doesn't already contain a tag"? That the version isn't a tagged release, i.e. already released?

[ehelms]

@waldenraines Correct, it looks to see if the version listed in the current bower.json has a tag with the same version number and halts.

[waldenraines]

ACK.

[jcoufal]

Was waiting for your last answer, but came too late, anyway ACK :)