Given that you are going to have to test this functionality for 3.4, why not make it a run-time configurable option and deliver it to customerY configured out at runtime?
How can I set up my SCM process with multiple environments for multiple customers?
Need to find an improved SCM solution for the following scenario:
- application is developed by four developers
- currently have 8 customers
- we have a DEV, TEST, QA, and PROD environment set up for each customer internally (roughly 30-40 total environments, each with it's own DB instance)
The present issue lies around the subject of security tokens that are stored in a table in each instance of each customer's DB (meaning there are 30-40 different lists of security tokens, depending on the customer and the internal environment related to that customer).
Example: if customerX states that it would like a secuirty token added that allows it to "Create a Widget", we would add a "Create a Widget" entry into the security token table of customerX's DEV DB.
Problem with example: let's say that customerX's DEV DB (and therefore the "Create a Widget" functionality) corresponds with code v3.4. we'd then implement the "Create a Widget" DB entry and code functionality on all customer environments that equal v3.4. however, customerY decides that they'd like that functionality withheld until v4.0.
How does one track said changes on a granular AND high level so that we're not sending customerY functionality that its not ready to receive?