We have a build that is currently churning along just fine. We use plan branches to help keep our own sanity (rather than create n additional builds, one for each branch we need to maintain, then age them off). One of the problems that I've now come across is if we have a "new" artifact (new capability, to be released in, say "release 1.7"). In our repo, "main" tracks "all current development tasks", and we branch off to create maintenance releases (so, we have a 1.0.x, a 1.1.x, a 1.2.x, etc up through a 1.6.x maintenance branches - though we only really need to keep track of "what's at least in production").
So far, we've been managing things just fine with releases up through 1.6.x. However, in 1.7.x, we'd like to create a new capability and deployable component (call it new-capability.jar). So, I edited our build plan to create a definition for the new artifact (new-capability.jar found in new-capability/target, with new-capability-*.jar as the target for the artifact). The problem is, any deployments we do with 1.6.x now fail, since it can't find the artifact "new-capability.jar".
How do other people handle this situation? Do you create multiple build plans for a given project, one for each release? Do you have a "dev build" that runs, then when the time comes to create a "release branch", clone that project, and change the "target" branch from the "Repositories" heading for the Plan? If you do that, how do you manage automated testing of feature branches? (by default, we also build all feature branches, with some pattern matching of the feature branch name - we've gotten pretty good at training our developers to use feature branch names that correspond to an existing ticket so that's easy to only build actual feature branches that are planned for merging in the future).
