There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

What language is the product written in?
–
user1249Mar 13 '11 at 16:56

3 Answers
3

For the most part, I use branches. On several rare occasions, I clone an entirely new client specific copy of the repository. The main point being, you want everything to stay 'related' so that merging and perhaps even cherry picking doesn't have to proverbially suck.

I follow the same rule that I follow when making a fork of any other open source project. If I need the project to go in a direction that most people involved would consider overly localized and specific to my own needs, I fork it. If the client's needs are digressing enough from the main effort, fork off another repository.

Otherwise, it is not at all uncommon to maintain branches for various architectures, so branches for particular clients that don't require you to deviate too far from the main development focus would serve basically the same thing.

Then again, there's nothing wrong with cloning one new repository per client. The point is, keep them all related so that your version control system helps you manage merges, bisections, tags and all of the other lovely things that we count on them to do.

Each time a feature is completed we trigger the automated build script and we make it immediately available in a special area called "BETA". It's fully automatic including web page update & upload. It's called BETA because it is a term well understood by our users. But it's purely development builds. Ready to be consumed by them. The fact it's a BETA page, the user accepts imperfections and the fact they become implicitly tester of that build.

At the end of an iteration, we decide to do an official release (newsletter, website change, etc) or delay to the next iteration.

During the process, we receive feedback from our customers continuously. Sometimes, we address a feature immediately. We made it available very quickly trough those dev builds.

If we face an annoying bug, we fix it on the trunk and merge it to the branch we did when we released the previous version. And update the file in the official download area silently and notify the users that have been affected by the issue.

Doing so give us the following advantages:

We control our release process. Our customer feel it and then trust us more.

Some customers are more eager to provide valuable feedback as they see it matters to us. Many innovations come from that channel.

Our customers know that we are continuously building on top of what they paid for, and therefore have the (real) feeling it worth the money they invested in it.

That's just an overview of the process, but I'm sure you get the point.

You do not address his delivery problem. Have you trained your users to update every 6 months?
–
user1249Mar 13 '11 at 16:59

They can subscribe to a special mailing list to get a notification when a build is available. Also within the application, they receive a notification when an official release is out.
–
user2567Mar 13 '11 at 17:27

This is very similar to our process. Our heavy users spend most of their professional live using the code, and are always making suggestions, sometimes even submitting desired code patches for features thay consider critical. Some bug fixes, or feature enhancements we might only make available in the Beta, if the code change looks to be risky. Our application is highly techical with very sophisticated users. Other application areas could have quite different characteristics.
–
Omega CentauriMar 13 '11 at 17:39

There's a great book called Continuous Delivery that might help you. Also, you might want to look at a process called Software Product Lines which addresses approaches to maintaining a group of closely related software branches. We used that technique when I was at Convergys (which handles billing for the majority of the Wireless and Internet service providers in America using a single product that is customized for each of the providers).