bradymiller wrote on Wednesday, October 12, 2011:
Hi,
Was hoping to get thoughts on what to have the next OpenEMR version be for the next release (in the future). At this point, it will be 4.2, but I am unclear if this means OpenEMR will need to be re-certified. To avoid this issue, would it be better to make it 4.1.1 , or does this matter. I’m clueless on this subject, so was hoping to get guidance.
thanks,
-brady
tmccormi wrote on Wednesday, October 12, 2011:
If you use 4.2 we will have to re-certify. The certification is for version 4.1 So 4.1.x is fine. We have to be careful that we do not break anything that was done as part of the 4.1.0 certification process. A significant about of testing and QA will be needed.
I think we can work on 4.2-dev, but any official released patches should use the 4.1.x incremented with each patch, similar to how we do the database versioning. Every patch set should be number and easy to identify by the users.
By the time we are ready for a 4.2 there will be new certification criteria that will be required to be tested anyway… keep those donations coming so OEMR will be able to afford the next go-round.
-Tony
bradymiller wrote on Wednesday, October 12, 2011:
Hi Tony,
That sounds good. Hopefully will have a improved patch mechanism (to allow database mods, especially considering a bunch of keys need to be placed) in order to extend 4.1 as long as possible. Speaking of donations (sorry it’s way off topic), how is OEMR doing (hopefully the omnipresent donation banner on both sites has brought in some donations).
thanks,
-brady
tmccormi wrote on Wednesday, October 12, 2011:
Brady,
oemr.org is doing pretty well. Several new members and some new corporate sponsors of late. Thanks for asking.
-Tony
www.mi-squared.com
bradymiller wrote on Wednesday, October 12, 2011:
Rod, Tony and everybody,
Because of above issue, we may want to be more aggressive towards what we take over from ‘master’ to ‘rel-410’ (after some testing time in ‘master’ of course) for patches to 4.1. Rod, I think you have two commits or so that have not been ported over to 4.1 (do you want them ported over and included in the 4.1 patch?).
For the database mods, thinking of putting all the sql_upgrade.php script functions into a library file, and then making an additional sql_patch.php script (uses the same functions) for patch updates and storing them in sql/4_1_0/4_1_0_1_patch.sql etc.
Then patch steps would be unzip, and then run the sql_patch.php via web browser (would be included in the zipped patch). So, then still keep the patch cross-platform (ie. easy to maintain).
Just shooting out ideas here; feel free to chime in if have a better idea.
-brady
sunsetsystems wrote on Thursday, October 13, 2011:
Brady, can’t we consider “master” to be the 4.1.1 branch? I’d prefer that rel-410 reflect release 4.1.0 plus bug fixes.
bradymiller wrote on Thursday, October 13, 2011:
Hi,
One more important question is at what date does the certification expire?
I can go either way here. If we continue what we are doing (a release every 6 months or so), then perhaps 4.1.1 (rather than 4.2) for the next release is better (it is easy to change master to 4.1.1, if wanted), which also gives us much more flexibility in the future. This won’t allow us to increment version number via patch as Tony wants, but our current patching mechanism doesn’t allow that anyways even with the new proposed mechanism to update the database (each patch is a combination of all previous patches plus the new stuff). Agree will be important to QA before the release, which shouldn’t be too tough since Visolve did so well documenting the NIST certification stuff.
So the question is, should master be 4.2.0 or 4.1.1 or somewhere in between? In terms of utilizing the least amount of resources to produce the patches, maintain the releases and keep certification, I think 4.1.1 may be better. With this strategy, would then plan the patches to include bug fixes and any feature upgrades needed to support MU.
thoughts?
-brady
bradymiller wrote on Thursday, October 13, 2011:
Also Tony,
I just noted your message regarding oemr.org . Great news to hear things are well and members are being enrolled.
-brady
bradymiller wrote on Thursday, October 13, 2011:
Also,
(sorry for my excessive messages here)
Could always compromise and do 4.1.5 or something too…(although it looks kind of ugly)
-brady
yehster wrote on Thursday, October 13, 2011:
My vote is to make the master branch=4.1.1 since we don’t have a definitive number scheme in place already and that will prevent the need to re-certify. It will be least confusing IMHO to go with 4.1.1.
-Kevin
bradymiller wrote on Thursday, October 13, 2011:
Hi,
Sounds like 4.1.1 (for the master branch) is the consensus. Will plan to change this sometime over the next couple days.
-brady
tmccormi wrote on Thursday, October 13, 2011:
Certification is FULL EHR for 2011/2012.
4.1.1-dev for the master I think would be best as well
-Tony
tmccormi wrote on Thursday, October 13, 2011:
I have question about the source base and the patches… The rel-410 branch is different from the v4_1_0 tag, I assume the tag is were the installs and tar balls were created from. So, can I further assume the the difference is applied patches? If so we should at least tag the Patch point as well 4_1_0_x …
-Tony
bradymiller wrote on Friday, October 14, 2011:
Hi,
Just changed and committed the master branch to version 4.1.1-dev .
-brady
bradymiller wrote on Friday, October 14, 2011:
Tony,
You are correct on the branch/tags. rel-410 is a branch that contains stuff in the patches, while V4_1_0 tag is a snapshot where the 4.1.0 release was taken from. My concern with tagging every patch is that we would “litter” the repo with a huge number of these tags over time.
-brady
achc wrote on Thursday, February 16, 2012:
Hi All,
I was curious if there was a target date for the 4.1.1 release. From the above it looks like, based on a six month schedule it may look like April?
We’re running 4.0 and were in a training and transition phase so we figured we’d wait until upgrading. Is that even a necessary plan? Or should we just go ahead and do it since it won’t make much of a difference?
Thanks
bradymiller wrote on Friday, February 17, 2012:
Hi,
No real target date yet. Not many big differences between 4.1.0 and the 4.1.1-dev (a fix to ensure compliance with newer version of Windows XAMPP-WAMP and a dated-reminders feature, which are both still in testing phase), so would suggest just going ahead with the 4.1 upgrade, since I’m guessing the 4.1.1 release will be released after April.
-brady
bradymiller wrote on Friday, February 17, 2012:
Also,
Remember to install the latest patch after the upgrade:
http://open-emr.org/wiki/index.php/OpenEMR_Patches
-brady