Hi Dawn, Our tasks for when we do a full system upgrade are 1. Check our modules to see if they work, if they don't investigate bugs and send code to developers to fix it, then test it again 2. Test public modules which we use and if they don't work file bugs and fix them if necessary 3. Wait for updated MVP dictionary (this will be in the future when we start using it) 4. Redeploy custom interface 5. Deploy in test server and check to make sure all data is upgraded and that there are no bugs. If there are bugs, fix them. 6. Make backup of all current systems that we are hosting 7. Create material to provide to users about the upgrade and what this will mean to them 8. Train technical staff to answer possible questions that will arise from upgrade 9. Deploy in all of the OpenMRS instances that we have
For us this is still hypothetical because we haven't upgraded from our 1.6 instance. Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> Moderador, GHDOnline.org <http://www.ghdonline.org/> On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[email protected]> wrote: > Hi Everyone, > > On the recent developers forum we talked about ways in which OpenMRS has > changed the road map focus from version numbers (updates to the core) to a > road map focused on what's most important to implementations (features and > functionality). What we envision in the long term is that implementing > sites will drive the direction of development.. > > So as we move in this direction, what we want to know is: *How often > should full system upgrades happen?* > > One of the things we also want to understand in your answer is what the > overhead is for an implementation to update to a new release. This may > include consideration that a roll out needs to occur over multiple sites > and/or the resources and time it takes for an implementation to do thorough > testing. The more information you can provide, the better! > > Thank you in advance for your feedback. :) > > > > All the best, > > -Dawn > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
