Should we retire the Allergy API module GitHub project?

Hi all,

Now that the allergy api module code has been migrated to the OpenMRS core, should we talk about retiring the allergy api module github project? I spent quite some time browsing through the code and worrying why it wasn’t working until @wyclif explained that the core had been migrated, and was no longer in use :slight_smile:

I do not think we should retire it yet. Because even our latest 2.3 reference application release is basing on this module. :slight_smile:

I’m curious what our would mean to “retire” the module.

Definitely it needs to stick around as long as we are still supporting platform versions <2.0.

That said we aren’t doing any active development on the module at this point, and any new allergy API-related development should happen in openmrs-core.

I kind of agree with Suranga, may be i can rephrase, we as OpenMRS developers i doubt if we are going to do any further development on the allergyapi module. I believe we need to update allergyui to depend on core and not allergyapi module and then we remove allergyapi from the distro. If someone wishes to continue with developing the module, that is up to them, but we need to be clear and mention in the read me file of the module in github that openmrs will no longer be actively working on the module going forward.

1 Like

Hmm… I think @wyclif brings up a good point… is there a way we can continue to have allergyui support platforms earlier than 2.0 without branching? How do we handle that prior to Platform 2.0 allergyui would require the allergyapi module, but once we are on Platform 2.0 is doesn’t? Would an “aware_of” dependency in the config handle this?

We also may want to consider backporting any bug fixes made to the allergy component of Platform 2.0 to the allergy api module, though I think this would be rare and only in the case of critical bugs.

Mark

It also implies that since allergyapi will depend on 2.0, so there might be java compatibility issues especially when since master now compiles against and requires java8

fyi: