View source for To Feature Branch Or Not To Feature Branch

==Topic proposals that were merged into this sesion==

* What makes a build a release?
* How does Continuous Delivery effect the rest of the organization (sales, marketing, etc.), especially for a product, and not a SaaS company?
** there weren't many people with such experience
** hallway conversation suggested to check how fast existing customers react to updates - no point releasing if they don't use it
* Feature Branching vs. Feature Toggles


==Feature Branching vs. Feature Toggles==

* we thought the branching discussion was resolved years ago, but now they are back with git! (any links to the old discussions?)
* long lived branches cause problems
* tools are better than they used to be
* long live feature branches can cause problems - nested if hell if not removed quickly after the release
* both require a lot of discipline
* any practice that prevents you from refactoring is inherently a bad practice
* both of these practices only seem to cause problems on larger teams
* only try any of the approaches if you really have to!
* CI tools would be great if they could handle multiple versions of dependencies, and should use their IDLE time to build these
** what if I merged this branch to this other branch? would all tests pass? 
** warn if violating backwards compatibility - e.g.: in a large team, with an eclipse like plugin architecture, if I built my plugin against an older release, it should work with all releases since, so when I go to work on this plugin again, I can be assured that I can upgrade my dependency to the latest without worrying about potential issues, so that I don't have an excuse to stick with the old version

'''A release is a build with confidence!'''

==Video Recording of the Session==

* http://skillsmatter.com/podcast/agile-testing/to-future-branch-or-not-to-future-branch