Question

We have a software product that evolves at the rhythm of clients’ needs and of a more general roadmap.

Because we are in a SCRUM project environment, it happens very regurlarly that a new feature makes its way to the product, and then we are confronted with the choice of:

• implementing this feature in an already released branch (not really the point of having a branch, then)
• making a new branch – but then we have a branch every three weeks, and it is just not maintanable anymore

Not releasing the new feature is not an option, the clients don’t want to wait for a long term milestone plan to get the features they want, and it’s not always faisible to move the feature in a client module – sometimes we need to change the core of the product…

Has anyone any feedback on a good practice given those kind of constraints ?

Answer 1

I’d suggest the following, which we use in my current environment: treat the unplanned feature like you would a security fix.

• Each planned release (e.g. 3.0, 3.1) gets its own version number, and its own tag in source code. After it’s released, you don’t touch it.
• New features after a planned release go into the next planned release (e.g. 3.2)
• If you must modify a released version of the code, it’s an ‘unplanned release’ and gets a patch version number (e.g. 3.1.1, 3.1.2). All changes:
  • Get implemented in a new branch based off of the latest patch to that release (e.g. 3.1.1 is created from 3.1.0, 3.1.2 is created from 3.1.1)
  • Are immediately merged to trunk, so they also get into the next planned release
• After implementing the unplanned feature, you turn the branch into a tag (aka don’t touch it anymore) and go back to working in the trunk.

This way, each unplanned feature gets a branch, but only long enough to make a new release and merge into trunk. You do almost all of your work in one place – trunk – and don’t have lots of merging work to do.