OpenMRS 1.9.0 RC2 Release!

classic Classic list List threaded Threaded
8 messages Options
Daniel Kayiwa-2 Daniel Kayiwa-2
Reply | Threaded
Open this post in threaded view
|

OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes.

The standalone version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module, and download it from here.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community


--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall. 

[hidden email] from OpenMRS Implementers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.  

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
Wyclif Luyima-2 Wyclif Luyima-2
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types.

Wyclif

On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[hidden email]> wrote:
I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]


[hidden email] from OpenMRS Implementers' mailing list
Wyclif Luyima-2 Wyclif Luyima-2
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

An implementation is only required to have at least one map type that will be used as the default for concept mappings when sharing metadata through occ and metadata from versions earlier than 1.9, and there is a global property for it. I would be fine with explicitly picking the default map type, i think should be 'same-as' and then only hard code its uuid.

Wyclif

On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[hidden email]> wrote:
The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types.

Wyclif


On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[hidden email]> wrote:
I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]



[hidden email] from OpenMRS Implementers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

Hi Wyclif,

I would think that if core is automatically creating any metadata, it should be doing so with fixed UUIDs.  It shouldn't necessarily make assumptions that these won't change (eg. there is nothing stopping an implementation from deleting and re-adding them), but it should at least make it default to the same UUID, IMHO.

Mike


On 03/30/2012 12:02 PM, Wyclif Luyima wrote:
An implementation is only required to have at least one map type that will be used as the default for concept mappings when sharing metadata through occ and metadata from versions earlier than 1.9, and there is a global property for it. I would be fine with explicitly picking the default map type, i think should be 'same-as' and then only hard code its uuid.

Wyclif

On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[hidden email]> wrote:
The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types.

Wyclif


On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[hidden email]> wrote:
I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]



[hidden email] from OpenMRS Implementers' mailing list

[hidden email] from OpenMRS Implementers' mailing list
Andrew Kanter Andrew Kanter
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

In reply to this post by Wyclif Luyima-2
I would NOT default to SAME-AS this is a narrower and special status... The more common would be IS-A or narrower-than. Our concepts in general are usually NARROWER than the concept being mapped to...

Andy
 
--------------------
Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University

Email: [hidden email]
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter


From: Wyclif Luyima <[hidden email]>
To: [hidden email]
Sent: Friday, March 30, 2012 12:02 PM
Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

An implementation is only required to have at least one map type that will be used as the default for concept mappings when sharing metadata through occ and metadata from versions earlier than 1.9, and there is a global property for it. I would be fine with explicitly picking the default map type, i think should be 'same-as' and then only hard code its uuid.

Wyclif

On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[hidden email]> wrote:
The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types.

Wyclif


On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[hidden email]> wrote:
I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]



[hidden email] from OpenMRS Implementers' mailing list



[hidden email] from OpenMRS Implementers' mailing list
Andrew Kanter Andrew Kanter
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

In reply to this post by Wyclif Luyima-2
Agree that the UUIDs for the concept mapping types should be standardized.
 
--------------------
Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University

Email: [hidden email]
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter


From: Wyclif Luyima <[hidden email]>
To: [hidden email]
Sent: Friday, March 30, 2012 11:56 AM
Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types.

Wyclif

On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[hidden email]> wrote:
I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables...

I've got a question regarding changeset 20110301-1030f.  This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type.  Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations?  I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward.  Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation?   This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations.

My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :)

Take care,
Mark




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Daniel Kayiwa [[hidden email]]
Sent: Friday, March 30, 2012 7:01 AM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release!

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>.

The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community

--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall.
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]


[hidden email] from OpenMRS Implementers' mailing list



[hidden email] from OpenMRS Implementers' mailing list
Robby O'Connor Robby O'Connor
Reply | Threaded
Open this post in threaded view
|

Re: OpenMRS 1.9.0 RC2 Release!

In reply to this post by Daniel Kayiwa-2
Congrats to all!

On 3/30/2012 7:01 AM, Daniel Kayiwa wrote:

Greetings to everyone!!!

We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes.

The standalone version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start.
For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here.

We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module, and download it from here.

Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system.

If no major bugs are found, this will become the official 1.9.0 release in a couple of days.

Upcoming End Of Life Announcements:
The 1.6.x line will reach EOL with the next major release (1.9.0)

A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!!

Daniel Kayiwa
On Behalf of the OpenMRS community


--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall. 

[hidden email] from OpenMRS Implementers' mailing list

[hidden email] from OpenMRS Implementers' mailing list