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

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!