develop branch?

[jeblundell]

Hey guys,

Excellent work so far. I'm very keen to contribute to this project and I was just wondering what people would think about creating a develop branch, i.e. allow incorporation of pull requests to progress development, but at the same time there's a clear, stable branch (master) for the public to use?

[tompollard]

Hey Jim,

Thanks for the positive words and we'd love to benefit from your contributions. Setting up a development branch is a good idea and I'll do this shortly. It would be good if we could work out how best to synchronise the code with MIMIC versions too (v1.3, v1.4 etc), so this is also something to think about.

Tom

[jeblundell]

The issue of matching code with database is a fairly substantial one. I was wondering if one way of doing it is for code to only work with the latest version and create a set of views that make it seem from the code's point of view that older versions are like the current version?

So looking at the changes to MIMIC:
"The EDTIMEOUT column was renamed to EDOUTTIME in the ADMISSIONS table for consistency with other timestamp columns."

Let's say that V_ADMISSIONS is our virtual ADMISSIONS table. If you have the latest MIMIC database version then V_ADMISSIONS is just the name of ADMISSIONS. If you don't then, V_ADMISSIONS is a materialized view, which (if the above was the only change) would SELECT * from ADMISSIONS, but with EDTIMEOUT renamed to EDOUTTIME. From our code's point of view then it doesn't matter what version of MIMIC you have, we can treat it the same.

"Hospital expire flag was in the wrong table - now moved to ADMISSIONS table. EXPIRE_FLAG added to PATIENTS table."
This is a little trickier. For latest version, again V_ADMISSIONS and V_PATIENTS simply point at ADMISSIONS and PATIENTS, job done. If you have older version of MIMIC then (if I'm reading that right), V_ADMISSIONS would be join between ADMISSIONS and wherever EXPIRE_FLAG used to be, returning SELECT * FROM ADMISSIONS plus EXPIRE_FLAG from wherever.

This would mean going through every single change and working out how to fake it, which is not a small task...

[jeblundell]

Actually, have thought about this a bit more: as nice as a solution that might be on the surface, it's probably easier just to require contributors to check version compatability and provide alternative versions where incompatible. Then during build/install, can auto-detect or take user provided version. Much less of a headache.

Theoretically we could keep separate git branches, but that's a lot of faff and requires ensuring that end user gets the right branch.

[alistairewj]

Yeah, usually we'd prefer users to not use older versions because they probably contain bugs which would affect subsequent analysis. A lot of changes are innocuous but some are quite important. If a script crashes because of version, and we can somehow inform the user that they need to update their copy of MIMIC, then that's best.