2-Version software: Best VCS approach?

Question

I suppose I'd better explain my situation:

I'm in the process of developing some software, and I'm at the stage where I'd like to split my project into two branches which differ in features. It so happens that this application is an Android application which I will be deploying on the Market, which has the constraint that every app must have a unique package identifier (sensible, no?).

My current approach has been to clone the git repo of my original project, but this causes issues with package names. I want the system to be robust enough so that a bugfix/new feature on one branch will merge into another branch, but only when I want it to.

Does anyone have any suggestions?

Answer 1

I handle that exact case myself for a paid app and trial version that have the same codebase. I am using SVN, but any version control software that supports branching would work.

I created a branch for the trial version from the trunk.

Then I modified the trial verion's AndroidManifest.xml to change the package name, adding .trial on the end. I then had to also update all the activity java files to reference the correct R class.

My paid app package is com.hewittsoft.baby
My trial app package is com.hewittsoft.baby.trial

In my activities on the trial I branch I do this

import com.hewittsoft.baby.trial.R;

and that causes any references to R.id.textField (or whatever) to work.

After I did those steps I can develop on the main branch and then merge over any changes into the trial version without too much pain.

Answer 2

If the only issue is a packaging and release management issue, you could isolate those steps (rename the package, and test it in a target environment) from the historization cycle within one Git repo.

So you could go on, separate your development, one feature per branch, keeping the same package names for both (in order to easily merge fixes from one to another).
But then, to test and deploy one of those two versions, you could have a script in charge of renaming the packages, recompiling, packaging (jar) and deploying the result in the target test environment.