zhhealthcare wrote on Thursday, May 27, 2010:
Hi
I had a question as a newbie developer. We are designing some new additions to certain portions of the OpenEMR. We need to implement these in 3.2 since our costumers are using it. However I was advised to develop it in version 4.0. So here is my question: if we do develop this in 4.0 can you guys revert it to 3.2 to be used by all without having to recode the whole thing in 3.2?
Sam
stephen-smith wrote on Thursday, May 27, 2010:
I’m fairly new to the project, too. However, my understanding is that new features are not being added to the 3.2 branch. New features will only be added to the development tip - 4.0.
If you want to develop against 3.2 but still contribute your changes to the 4.0 branch, using Git should make things a bit easier.
The workflow would be something like this:
git checkout -b my-feature rel-320
# Hack, test, and whatever else until you are ready to share.
git checkout -b my-feature-for-upstream my-feature
git rebase rel-320 -onto master
The “rebase” may encounter issues that it can’t auto-resolve and that you will have to fixup manually. Using the command (git mergetool) can automate parts of that - especially if you have a 3-way merge tool installed where git can find it; I use kdiff3. Once you fix things, you can (git rebase -continue) to try and complete the operation.
Moving patches is not always difficult, but as 4.0 diverges from 3.2 there will be more and more things that have to be manually resolved.
After the whole rebase process is complete, you’ll have a branch named my-feature-for-upstream that would be suitable for committing to CVS HEAD.
bradymiller wrote on Thursday, May 27, 2010:
hey,
Generally, I only take bugs back to the stable version patch. However, this release cycle is special since its gonna be much longer than others, so have been taking the stable and straighforward features back to the 3.2 patch (for example, the next patch will place the insurance form in the new patient screen). As Stephen suggests, for your clients do in 3.2, but submit to us in development tip (4.0); this is where git (as stephen outlined above) is very helpful. It’s a bit more work for you, but it’w well worth it for you. Because, otherwise you have to re-create the feature for your customers when they upgrade to 4.0 and so on (so by getting it in the development tip, you’ve put your feature in the codebase permantly).
-brady