4.1.2 Release Planning

tmccormi wrote on Wednesday, March 14, 2012:

All - I think it’s time to start planning for officially releasing a 4.1.2 version.   We are at patch 8 on 4.1.0 and I think too many more patches will start to be silly :-)  Stability is good in 4.1.1-dev.

Possible remaining TO DO
1) Finish 5010 support for 835 (ERA), 837 (Claims), 270/271 (Eligibility)
2) INNODB updates (step 1 as discussed)

Other thoughts?

-Tony

bradymiller wrote on Thursday, March 15, 2012:

Hi Tony,
What happened to 4.1.1? :slight_smile:
-brady

tmccormi wrote on Thursday, March 15, 2012:

It could be that too.  I (personally) like the fairly common model of odd numbers be development unstable and even being stable releases.  But I don’t care enough to argue about it…  more important to start this process I think.
-Tony

bradymiller wrote on Thursday, March 15, 2012:

Hi,

I’d prefer 4.1.1, but I’m not too attached to it.

On the timing, perhaps we should think about freezing the code for any new features in mid April and plan the release several weeks after that.
Would be nice to get the following in this release(will have a better idea if this is a possibility in several weeks):
1. Z&H’s practice management and billing modules
2. Z&H’s couchDB support
2. Complete the 5010 support
3. INNODB conversion
4. ICD10 support

thanks,
-brady
OpenEMR

bradymiller wrote on Wednesday, April 11, 2012:

Hi,

Placed a wiki page to begin to track the new release (note there are still some features/bugs that may take some time; feel free to modify/discuss):
http://www.open-emr.org/wiki/index.php/QA/Release_Process#Version_4.1.1

-brady
OpenEMR

yehster wrote on Wednesday, April 11, 2012:

Given that an official release should be stable and well tested, I don’t believe that it’s appropriate to include the CouchDB stuff.

The CouchDB code submission doesn’t work yet, and hasn’t seen any real testing.  It has the potential to affect a high importance feature (document uploads) even if you don’t configure your system to use it. 

Plus, as I commented in the code review, a much simpler and equally robust if not more so way to scale would be to setup a secondary file server and use symbolic links or mount points.

bradymiller wrote on Wednesday, April 11, 2012:

Hi,

Provided a bunch more details and links on the release proposal:
http://www.open-emr.org/wiki/index.php/QA/Release_Process
(please feel free to contribute to it and/or take responsibility for a fix/feature )

Regarding testing, plan to allow about 4 weeks of testing after the main feature/bug fixes are done, so this is not a reason to not allow new features.

Regarding CouchDB, here’s the tracker for it:
http://sourceforge.net/tracker/?func=detail&aid=3497510&group_id=60081&atid=1245239
And here is the last code review:
http://github.com/zhhealthcare/openemr/commit/6787bcacc6b77359b609693e529aaf7d4d7b55ef
Please note that is does work, but there are still some issues that need to be fixed. My thoughts on the review were that when those issues were fixed, it would be ready for committing to sourceforge. To address whether this feature makes any sense, my comments towards this are:
1. There are always many ways to do something.
2. It is an option (a rather sophisticated option that will require a strong skillset and also require ensuring adequate backup/restore mechanisms by the user).
3. Z&H appears to be using this currently on their servers, so it is getting use.

If the community really feels there is no use for this option (kind of tough to argue this, though, since it is being used by somebody in the community), then I suppose it wouldn’t make sense to place this in the codebase (although I think the code is well done and documented, it does further complicate the code).

-brady
OpenEMR

yehster wrote on Thursday, April 12, 2012:

My main point is that if the goal is a stable/reliable low bug count release, we shouldn’t be introducing a complicated feature that has only seen limited tasting and only has limited usefulness for the next “official release”.

If you look at release cycles of other open source projects, there comes a point when feature freeze happens unless something is showstopping so that you can really understand  the status of your code.

More isn’t always better.  Sometimes it’s just more.

tmccormi wrote on Thursday, April 12, 2012:

I agree with yehster here.   That kind of functionality needs extensive testing and has limited appeal.  Our limited testing resources should be applied to 5010 testing and more critical user features.
-Tony

bradymiller wrote on Thursday, April 12, 2012:

Hi Tony and yehster (and everybody else),

I completely agree that we should not add features during the code freeze phase before a release. However, we are not in the code freeze phase and as the wiki page link above shows, there are still several ongoing features in the pipeline that we are waiting for before the release (as an aside Tony, is there any other 5010 stuff in the pipeline that you know of).

Note that the couchDB code has gone through four code review (with extensive testing by myself) and revisions and is not really that complicated (code is much more clear if use the ‘git diff -w’ command to view it (-w switch doesn’t show lines with only white space changes).

As touched on, I don’t think the imminent release or the apparent complexity of the code are valid reasons to turn away Z&H’s code if they submit a revision before the code freeze. If the community felt this feature was not useful (ie. not worth the additional code complexity), then that would seem to be a more valid reason. To come to this conclusion, though, I think one needs to review/test their code first. I’m also curious what Z&H thinks and how it is working on their servers.

-brady
OpenEMR

bradymiller wrote on Tuesday, May 08, 2012:

Hi,

Z&H’s couchdb is testing well and is ready for commit in my opinion (it has gone through 8 or so revisions). Wanted to bring it up, because several contributors seem to be adverse to this feature. The code is really not that complex (recommend using the ‘git diff -w’ option to see the changes without whitespace mods) and it is testing well. We are also not in a release freeze yet. Thoughts?

thanks,
-brady
OpenEMR Project

bradymiller wrote on Tuesday, May 08, 2012:

Here’s the tracker item for the couchdb feature:
http://sourceforge.net/tracker/?func=detail&aid=3497510&group_id=60081&atid=1245239

bradymiller wrote on Wednesday, May 09, 2012:

Hi,

Quick 4.1.1 release progress update. Here’s the wiki page tracking this:
http://www.open-emr.org/wiki/index.php/QA/Release_Process

Things plan to still do before the code freeze:
1. Get ICD10 supported (guessing still have several weeks on this)
2. Fix the Layouts datafield length bug

Things need to have done before the release:
1. A user manual
2. Ensure the ubuntu package supports upgrading multisite instances

Guessing no code freeze for several more weeks (waiting on ICD10 support), so there is still several more weeks to get new code submissions into the next production release.

-brady
OpenEMR

biller2 wrote on Monday, May 21, 2012:

I have a question about dev 4.1.1.  I am testing it out on ubuntu 11.10 with MySQL version 5.1.58 and PHP 5.3.6-13.  The question/issue I seem to be having is with recurring appointments.  Take for instance I have a recurring appointment and edit it. If I save the changes to all appointments everything seems to work fine however, If I choose to save the changes to just the current appointment I receive the following
ERROR: insert failed: INSERT INTO openemr_postcalendar_events ( pc_catid, pc_multiple, pc_aid, pc_pid, pc_title, pc_time, pc_hometext, pc_informant, pc_eventDate, pc_endDate, pc_duration, pc_recurrtype, pc_recurrspec, pc_startTime, pc_endTime, pc_alldayevent, pc_apptstatus, pc_prefcatid, pc_location, pc_eventstatus, pc_sharing, pc_facility,pc_billing_location ) VALUES (?,?,?,?,?,NOW(),?,?,?,?,?,?,?,?,?,?,?,?,?,1,1,?,?)
then the current appointment vanishes leaving any previous and later appointments.  Is this a known issue or possibly something I’m doing incorrectly.  Thanks in advancey for any help guidance.   John

biller2 wrote on Monday, May 21, 2012:

After digging a little more I looked at the ~/interface/main/calendar/add_edit_event.php file and noticed there were some changes from the 4.1.0(7) file.  So as a test I took that file and replaced the one in the 4.1.1-dev version and the error no longer occurs.  I hope this bit of information is helpfull.  Would it be ok to use that replacement file or would I be breaking something somewhere else.  Thanks again John

bradymiller wrote on Tuesday, May 22, 2012:

Hi John,
Thanks for the bug report; I was also able to verify this bug. There have been extensive mods to /interface/main/calendar/add_edit_event.php, so using the old one may cause issues. The best thing to do is to fix this bug. Error is coming from a sql query that was modularized (related to a billing improvement commit) to the library/encounter_events.inc.php script (line 286). Perhaps Z&H can look into this?
-brady
OpenEMR

bradymiller wrote on Saturday, May 26, 2012:

Hi,

For an update on the OpenEMR 4.1.1 release plans, check out the following wiki page:
http://www.open-emr.org/wiki/index.php/QA/Release_Process

As noted, there are still several ‘Tickets Pending’(feel free to take a ticket that is not assigned). There is only one ticket that am waiting on before branching the code (ie. freezing the code for only bug fixes), which is the ICD10/SNOMED stuff:
http://www.open-emr.org/wiki/index.php/Diagnostic_Codes_Development#ICD10

The reason I propose to wait on this is because I’ve noted that the userbase for OpenEMR outside the US is growing pretty rapidly. Reason for thinking this is that 75% of downloads from sourceforge are outside the US and I’ve noted a lot more requests by translators to participate in the project. Supporting ICD10/SNOMED coding would be very useful for the international users, so figured it may be best to wait for this to be included in the OpenEMR 4.1.1 release (shooting for a code freeze date of 6/15 and a release in July).

thoughts?

-brady
OpenEMR

bradymiller wrote on Wednesday, June 13, 2012:

Hi,

Figured it was time for an update on the OpenEMR 4.1.1 release plans, which are tracked here:
http://open-emr.org/wiki/index.php/QA/Release_Process#Version_4.1.1

Still waiting on getting the ICD10/ICD9/SNOMED stuff (guessing one more week) more completed before going to a code freeze. There are also quite a few showstopper bugs (at least 10) that need to be fixed and I am sure there will be more. I am not begging yet (will do this in another couple weeks), but please feel free to take over a ticket/bug here (just put your name in place of ???):
http://open-emr.org/wiki/index.php/QA/Release_Process#Tickets_Pending

-brady
OpenEMR

cbezuidenhout wrote on Thursday, June 14, 2012:

I have done some of the mySql compatibility stuff changing type= to engine=

here is a link to the code :
https://github.com/tajemo/openemr/commit/bd237032da99eea1ee4a7965038faccfca8b07d0

  - Craig
    Tajemo Enterprises

cbezuidenhout wrote on Thursday, June 14, 2012:

fixed some bugs in prescriptions :

- fixed columns in list view
- changed cursor to a hand for table rows (feels more natural)
- stopped from from going to send screen after adding line item. Improves Work Flow
- automatically checks line items created on the current encounter. Improves the flow
- made print to html open in new window, works a bit better

link to code :
https://github.com/tajemo/openemr/commit/0a8a0b93f0f4e477f619b206dd4d4534a601eb5a

  - Craig
    Tajemo Enterprises