Fabric

E.g. the succeeded attribute and anything else which is backwards compatible (i.e. won’t break existing fabfiles.) and which is relatively important and/or useful. I don’t want to backport everything that’s compatible, because technically I want tertiary releases to be bugfix-only. However, I do want to lessen the gap between 0.9 and 1.0 so that the “feature pressure” of 1.0 is let up a bit — I don’t want to release it too soon after 0.9.

Will need to come up with a good way of cherry picking the commits (both implementation and docs/changelog!) while changing the “added in:” notes:

• Cherry-pick original commit, followed up with modification commit.
  • Plus: retains link to “original” commit in the master branch
  • Minus: means that the cherry-pick shows up as its own, incorrect state of the 0.9.x branch (i.e. anybody checking it out would see the wrong docs/docstring.)
• Do a local cherry-pick + modification + rebase, so that the upstream only sees the one commit.
  • Plus: atomic correctness (especially since there may be multiple commits affecting a given backported feature — e.g. 84fd8aa which affects a handful of commits, isn’t going to mesh well with cherry picking for a single change. This is why I need to be more cognizant of the docs related to feature changes!)
  • Minus: loses connection to original commit (outside of the commit message, which would be left with the “cherry-picked X” message of course)

Will also need to figure out whether to do all of these at once for 0.9.1 or 0.9.2, or to spread them out over a few releases for some reason.

Finally — the 1.0 version of the code will need updating at the same time so that it now includes the “change in 0.9.1” notes instead of “changed in 1.0”. If I'm lucky, merging back in from 0.9 will do this, but I foresee conflicts, in which case I should finally learn how to tell a merge to use one side or the other, beforehand.

The following (non-merge) commits are related to this ticket but don’t have #111 in their commit logs. Remember that you can mouse-over them to see the commit messages :)

In 0.9, cherry-picked or hand-copied from master:

• 4f3e4d18f2a99511dc8a179f140e6abd7e411207
• 729fba84271ccdc76cc061e73b1708ad8d695ed8
• b9554b6c3407be9e2885a351c010b31bfe885bac
• 88146a1e9f14ebb34a6f075e7945e8bee3dfdc63
• 2b6904c910a216a41f749705d55a2f684e41675f

In master, mostly just removing items from the 1.0 changelog now that they’re listed under 0.9.2 (also occasionally fixing the up-merges from 0.9 if they broke):

• b9554b6c3407be9e2885a351c010b31bfe885bac
• eeb0512c8166278713acf0171d30ba068e6ee69e
• 88146a1e9f14ebb34a6f075e7945e8bee3dfdc63
• 5c808cd5fb072ee4d54b22b489281663b2a1c06a
• 2b6904c910a216a41f749705d55a2f684e41675f
• acd5e6aee26ab84c9fece610364b0153f251d7c2

All other backports will be tagged with #111 and should show up below this description in the usual spot.