sassquatch2
v2.4.6
Published
Front end framework for Meetup
Downloads
1
Readme
Sassquatch 2
Sassquatch is a CSS foundation and framework for Meetup, built with Sass.
Documentation
Hologram documentation is built to github pages
An overview of basic Sassquatch2 conventions is also available in the wiki
Installation
Manage installation via bower:
"dependencies": {
"sassquatch2": "[email protected]:meetup/sassquatch2.git#master",
...
}
Development
Clone this repo and run ./setup.sh
.
Code guidelines and standards are documented on the wiki
We use the Gitflow branching model for development:
develop
- default branch for active development (all PRs diff againstdevelop
)- release branches - cut from
develop
, get merged intomaster
master
- only release branches and hotfixes get committed to master- master branch in theory should always contain the latest stable release
Grunt tasks
Command | Result
------------------- | -----------------------------
grunt
| By default, grunt recompiles Sass and rebuilds Hologram docs
grunt sass
| Recompiles Sass
grunt hologram
| Rebuilds Hologram docs
grunt clean
| Cleans compiled docs and CSS in docs/build
grunt ghpages
| Caution: commits compiled docs for your branch to gh-pages
Creating a release
Until I write the script for creating a release, the process is unfortunately manual.
Because we're using the git-flow branching model, all fix and feature commits flow into
the develop
branch. The master
branch is our "production" branch.
Beginning the release
We begin all releases with a release branch and a release tag.
- from
develop
, checkout arelease/X.X.X
branch - in
release/X.X.X
, increment the version number inbower.json
andpackage.json
- commit the result & push
git tag -a vX.X.X -m "tag message"
- git push origin vX.X.X
Once the tag ref is pushed to origin the version is available to install via bower in chapstick or elsewhere.
Finishing a release without chapstick dependencies
If the changes in your release/X.X.X
branch appear stable and do not require updates in chapstick:
- merge the release branch,
release/X.X.X
tomaster
- merge
master
intodevelop
- don't forget to rebuild docs! (run
grunt ghpages
inmaster
)
Finishing a release with chapstick dependencies
If your release includes breaking changes and requires code changes in chapstick, follow these steps:
- start a chapstick branch for your sq2 release
- set the
bower.json
version forsassquatch2
in chapstick to match your release number - if you need to make fixes to the
release/X.X.X
branch, you can retag the release to include your fixes (see below) - when your chapstick branch with the sq2 update releases to production, you can follow normal steps for finishing a sq2 release (merge the release branch to
master
) - don't forget to rebuild docs! (run
grunt ghpages
inmaster
)
Retagging a release
Sometimes you need to retag a release to incorporate new commits. Here are the steps for retagging a "1.5.0" release after you make a few fix commits to the release branch:
git pull
- fetches tag refs from origingit tag -d v1.5.0
- deletes the old v1.5.0 tag refgit push origin :refs/tags/v1.5.0
- pushes your delete of the ref to origingit tag -a v1.5.0 -m "My new and improved release 1.5.0"
- create new v1.5.0 taggit push origin v1.5.0
- push the new v1.5.0 tag to origin- in chapstick, just
bower cache clean
andrm -rf static/components/sassquatch2
then reinstallsassquatch2
to get updated commits for the tag