if there is anything i missed, PLEASE tell me. I'm thinking i should create tickets for each of these and set a 1.1.8 milestone so that progress can be tracked.
Just thinking out loud here, a lot of the commits on that list are not strictly bug fixes but rather small feature additions. If I were you I would probably make a decision between just back-porting pure bug fixes or simply bump the release number and release everything in master as 1.2.
This makes it tough on stuff like documentation because the site assumes that the API remains the same on each 1.x version. It would suck if you're using 1.1.7, look up the docs, see a 1.1.8-only feature, and try to use it in 1.1.7. (The docs label it as 1.x.) I think it would be a poor experience to make people browse to the docs for each 1.1.x release rather than the much simpler 1.x.
If this assumption has changed, then we should probably change the site to have docs for each x.x.x release instead of x.x.
touche chris. Is there something in the doc generator currently that we can mark when a feature was introduced?
I had plans to add some sort of history attribute that records changes to functionality. Simply recording when a feature is introduced wouldn't be enough, IMHO. Sometimes features could be changed or removed too. Would need to be able to record commit-style lines that explain clearly what happened.
results of backports going into 1.1.8.
For commits marked as no. I'll investigate them for a 1.1.9 release if one is warranted.
DONE - e5a633d
DONE - c0aa441
NO (too many conflicts) - 506f7b5
NO (too many conflicts) - edf3410
NO (too many conflicts) - 941ff00
DONE - 6c67e6e
NO (no test coverage) - d65a3f8
NO (no test coverage) - 6d687ee
NO (no test coverage) - 972dc3e
DONE - 2533efc
DONE - fa0f3f4
DONE (replaced) - a8e378e
DONE - bd1b6b7
DONE - d3a6319
NO (test coverage declares invalid) - aa04eb9
NO (test coverage declares invalid) - b212002
NO (breaking change) - 9412e07