Merge branch 'stable'
* stable: Release strategy post. doc gemfile changes Fix broken example charityware Conflicts: doc-src/Gemfile.lock
This commit is contained in:
commit
963eb3065b
@ -8,10 +8,10 @@ GIT
|
||||
PATH
|
||||
remote: ..
|
||||
specs:
|
||||
compass (0.11.beta.7.a58a66c)
|
||||
chunky_png (~> 1.1.1)
|
||||
compass (0.11.1.63cae60)
|
||||
chunky_png (~> 1.1)
|
||||
fssm (>= 0.2.7)
|
||||
sass (>= 3.1.0.alpha.249)
|
||||
sass (~> 3.1)
|
||||
|
||||
GEM
|
||||
remote: http://rubygems.org/
|
||||
@ -35,7 +35,7 @@ GEM
|
||||
rake (0.8.7)
|
||||
rb-fsevent (0.4.0)
|
||||
rdiscount (1.6.8)
|
||||
ruby-prof (0.10.5)
|
||||
ruby-prof (0.9.2)
|
||||
sass (3.1.0)
|
||||
serve (1.0.0)
|
||||
activesupport (~> 3.0.1)
|
||||
|
@ -14,7 +14,7 @@
|
||||
|
||||
// This will yield a radial gradient with an apparent specular highlight
|
||||
#radial-gradient
|
||||
+background-image(radial-gradient(45 45, #0ff 10px, #1e90ff 30px))
|
||||
+background-image(radial-gradient(45px 45px, #0ff 10px, #1e90ff 30px))
|
||||
|
||||
// This yields a linear gradient spanning from the upper left corner to the lower right corner
|
||||
#linear-gradient
|
||||
|
@ -8,6 +8,8 @@ The Compass team is proud to announce that v0.11 is released. With this release,
|
||||
|
||||
In this post, we summarize the new features. For all the nitty gritty details, see the [CHANGELOG](/CHANGELOG/).
|
||||
|
||||
Compass is Charityware. If you love this release, [please donate to the UMDF](http://umdf.org/compass) on our behalf and help find a cure for thousands of children suffering from mitochondrial disease.
|
||||
|
||||
## Sass 3.1
|
||||
|
||||
This release required you to upgrade to Sass 3.1. This release brings a ton of great new features that Compass now uses and you can too!
|
||||
|
@ -0,0 +1,93 @@
|
||||
---
|
||||
title: "Compass Release Strategy"
|
||||
description: "An overview of how Compass will be managing ongoing releases."
|
||||
author: chris
|
||||
---
|
||||
|
||||
Most of this is probably obvious, but it doesn't hurt to be explicit about such things.
|
||||
|
||||
If you're interested in contributing to Compass, please read the
|
||||
[Contribution Guide](http://compass-style.org/help/tutorials/contributing/).
|
||||
|
||||
Versioning
|
||||
----------
|
||||
|
||||
Most stable releases will be released as release candidates first
|
||||
(e.g `0.11.1.rc.0`) and then made into official releases after a day
|
||||
or so if they don't cause any problems.
|
||||
|
||||
Sass Dependency
|
||||
---------------
|
||||
|
||||
We will decouple major Compass releases from the Sass release schedule
|
||||
going forward. When Sass releases happen, we will issue patches to both
|
||||
stable and master branches to adjust to any deprecations and new
|
||||
features after they are fully released (which means we might have the
|
||||
changes waiting in a topic branch). Because Sass is very careful to not
|
||||
break existing stylesheets without deprecating first, this shouldn't be
|
||||
hard to pull off.
|
||||
|
||||
Stylesheet Progress
|
||||
-------------------
|
||||
|
||||
I do not want to see the compass stylesheets get frozen again
|
||||
like they did in v0.10 while waiting for the next major release.
|
||||
Compass users expect us to keep up with browser developments and we will.
|
||||
If this means that we need to make v0.12 become v0.13 because
|
||||
the stylesheets need to make some major change, then we will do that.
|
||||
|
||||
Communicating Change
|
||||
--------------------
|
||||
|
||||
All new features should have tests, docs, and CHANGELOG entries
|
||||
as appropriate as part of the commit.
|
||||
|
||||
Additionally, we now have a compass team blog that we can use to communicate
|
||||
about new features, best practices, or other Compass related stuff.
|
||||
It's easy to add a post, you just drop a markdown file into
|
||||
[this directory](https://github.com/chriseppstein/compass/tree/stable/doc-src/content/posts).
|
||||
Guest posts are totally welcome via pull requests.
|
||||
|
||||
Stable
|
||||
------
|
||||
|
||||
The stable release is were code lives for the next v0.11 point release.
|
||||
Commits should only go here if they are ready for release, until that
|
||||
point the code should live in your compass fork or in a topic branch.
|
||||
|
||||
Core team members, please use pull requests to manage the code review
|
||||
process for any change of significance and get sign-off from one other
|
||||
team member before committing to stable.
|
||||
|
||||
Changes that can go on stable:
|
||||
|
||||
* Browser support updates
|
||||
* Non-breaking stylesheet changes and minor features
|
||||
like new mixins or modules.
|
||||
* Bug fixes
|
||||
|
||||
Changes that can't go on stable:
|
||||
|
||||
* New deprecations
|
||||
* Major features
|
||||
* Big refactors
|
||||
|
||||
If you're not sure where to put something, just ask.
|
||||
|
||||
Rails 3.1 support is the exception to this rule, given the timeline
|
||||
assocated with that release, I will make a topic branch and we'll
|
||||
merge that to stable when it's ready.
|
||||
|
||||
Core team members will, after committing/merging code to stable, then merge those changes to master so it is up to date.
|
||||
|
||||
Master
|
||||
------
|
||||
|
||||
Master is where code goes to be ready for v0.12. This focus of this
|
||||
next release is making extensions easy to make, share, discover, install,
|
||||
remove, and use. Any and all ideas that you have related to this are
|
||||
welcome. At a minimum, I would like to have an extension directory
|
||||
app hosted on compass-style.org and make sure that compass knows about
|
||||
it and can install extensions by name from there.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user