0

I am curious about what source versioning strategy would others apply on a java project (web application) which is very probable to have customization for several customers.

The project will have a standard version, but for some of its customers there will be some customizations to be done (on different branches).

By reading this thread : What branching strategy should I use during the development/maintenance of a web application? I guess that the "Branch by release" would fit for the development of the standard version of the project.

Now while working on a customer branch there are some improvements/bugfixes performed on the code on which other customer/standard version would benefit this would mean that for each of the branches there will be merges & tests to be performed in order to be keep everything up to date.

As a constraint, for this project we are stuck with CVS as a source versioning system.

For versioning of the artifacts which are built we'll use maven (dependy : artifactId, groupId, version, classifier - customer name - in order to clearly distinguish the artifacts).

Community
  • 1
  • 1
marius_neo
  • 1,535
  • 1
  • 13
  • 28

1 Answers1

1

I would recommend creating a branch per customer AND a branch per feature and letting your trunk represent your "standard version".

Any small bug fixes would be merged back to the trunk and subsequently propagated out to all branches. The same would hold true for new features, as you would merge them back to the trunk and kill the branch.

All your customer branches would be long-living, and you would make your customer-specific customizations there and would release from those branches.

Marcus Swope
  • 134
  • 1
  • 7
  • Say that the trunk version evolves during the time to version 3 and one customer which has the code with changes equivalent to version 1 of the application decides to make an upgrade. This will generate a lot of effort when upgrading the customer branch to version 3. – marius_neo Oct 17 '11 at 09:37
  • If you are changing major versions, that usually implies breaking changes. Would your customer really expect customizations made to version 1.0 to be a part of version 3.0? It's doable, but it sounds like you need some better salespeople. :) As an aside, _any_ merging done with CVS is going to generate a lot of effort. – Marcus Swope Oct 17 '11 at 21:14
  • If for the version 1.0 the customer has paid for the customization (another dashboard, some extra business workflow) i see it as normal that the customer wants his customized features also in future versions. Concerning the CVS merging you are right. In the given situation do you have in mind a better option to for a source versioning strategy? – marius_neo Oct 18 '11 at 09:12
  • I don't think there's much else that you could do with CVS. With git you could potentially replay changes made on the "customer specific" branch onto the "next version" branch depending on the number of changes made between versions. This is why it will depend on if you're moving from version 1.0 to 3.0 or if you are moving from version 1.1 to 1.3, the branching strategies would obviously be different depending on the situation. I would go back to what I said before: customizations made from 1.0 are rarely expected to be backwards-compatible to 3.0 (hell, Microsoft rarely does this). – Marcus Swope Oct 18 '11 at 19:31