Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a project which will have basic and professional edition. The professional edition will have all the features of the basic edition. I am using git to manage the project's codebase.

I consider that I will fork repo of the basic edition after I completed it. Then, I will start to code the professional edition on the forked repo.

My problem is that if there would be a bug in the basic edition in the future, I don't want to fix the bug in the basic edition and professional edition twice. How to handle this situation?

share|improve this question
1  
"I will fork repo of the basic edition" / "I don't want to fix the bug in the demo edition and professional edition twice" Those two plans are mutually contradictory. You must choose one of them. In my opinion, plan 2 is way better in general, but we'd need much more context to be sure. –  Kilian Foth Nov 15 '13 at 12:22
1  
If you make all fixes in the basic edition branch, it should be save to simply merge them in the professional edition branch. –  MrSmith42 Nov 15 '13 at 12:26
3  
What do you deploy to your customer, source code or compiled binaries? If you deploy compiled binary, you are most times better off by introducing just a feature toggle which can be switched on and off at run time for activating the "pro" features. That way, when a customer wants to switch from basic to pro, you just send him a new license file, no need to send him a different application version. So you don't have to manage different forks/branches of your code at all. –  Doc Brown Nov 15 '13 at 13:02
    
@DocBrown I will just deploy compiled binary. Your suggestion seems reasonable. But, it seems to me that writing togglable features is more difficult than managing two repoes. But if there are some patterns that ease to write togglable features, then implementing your suggestion is the most suitable of all the other solutions. –  haitaka Nov 15 '13 at 14:30
1  
To my experience, making features toggable is often very simple, at least when your features are reasonable separated from a users point of view . But there is no general rule how to make features "modular", this depends fully what kind of features you have and how they are implemented in your code. Just try to keep the "feature entry points" small. –  Doc Brown Nov 15 '13 at 14:54

2 Answers 2

up vote 3 down vote accepted

I would not fork the pro edition: this would be almost like saying that it is a related, but different, project. It is not so: it's a fuller version, and it shares so much of the code that you rightly fear that you will have to fix a bug twice. So, don't do it and change your idea. You can implement a pro edition in different ways: distribute the full version and disable some feature in the basic version, adopt a modular solution where the pro edition has "more", or more powerful, plugins/modules...

So you share a core base and all the test, the bugfixes, the documentation and your investments in terms of time and resources will be useful for your project as a whole.

share|improve this answer
    
So, are there any patterns that ease to make pro features modular so that they can be switched off in the basic edition easily? This question might seem irrelevant with my main question, but if you recommend some patterns, it will be much appreciated. Thanks. –  haitaka Nov 15 '13 at 14:23
    
+1, exactly what I had in mind with my comment. @haitaka: read this blog post: martinfowler.com/bliki/FeatureToggle.html –  Doc Brown Nov 15 '13 at 14:44

Well, git is very nice in that it allows you to have multiple remotes.

For example, you can have this in your .git/config:

[remote "basic"]
    url = git@github.com:haitaka/project-basic.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[remote "pro"]
    url = git@github.com:haitaka/project-pro.git
    fetch = +refs/heads/*:refs/remotes/origin/*

This allows you, while being in your pro project, to do this:

git pull basic master

And it will merge the changes from the basic project into the pro project.

Of course, this will only work if the pro features are completely separated from the basic features, codewise.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.