[prev in list] [next in list] [prev in thread] [next in thread]
List: openmrs-dev
Subject: Re: Potentially releasing faster
From: Burke Mamlin <burke () openmrs ! org>
Date: 2012-11-22 3:54:29
Message-ID: CAKgo1ZZ7cj9WcWgOowpowBE1W4d5zhfdrLwB9+3vSdO5xrnOXw () mail ! gmail ! com
[Download RAW message or body]
We need a compromise between getting releases out quickly and being
realistic about what our implementers & devs can handle. There are
advantages to having our single-threaded approach (most working going to
master + three supported minor versions). A more complicated model would
probably create more pain than benefit. Perhaps some combination of the
ideas mentioned would help:
*Lower threshhold for a minor release when strategic priorities, feature
set, and developer cycles make it desirable & possible*
*Example: 1.10 released sooner with less than previously planned, but with
a few changes needed by the Mirebalais project*
*Increased effort to keep master releasable*
*Example: half-completed work is not pushed into master; more effort to
code long-running features in a way in which they can be "released" in
silent chunks*
*Allow for backporting backwards-compatible "features" when needed*
*Example: a "1.10" feature needed by implementations running 1.8.x that is
backwards-compatible could be backported*
*Easier upgrade path for implementations*
*Example: Continue working on ways to reduce the pain for implementations
to upgrade (e.g., refactor modules to participate in the release testing
process, consider impact on implementations when designing/organizing
changesets, etc.)*
Have an extra release here or there when it's strategically useful
shouldn't be a big deal. While upgrading can be a big deal for larger
implementations, it's not significantly different to upgrade one minor
version than it is to jump several minor versions at once (in fact, that's
what most the bigger implementations have been doing).
I doubt that the highest level of continuous delivery (the ability to
deploy a release with any change) is attainable for OpenMRS with hundreds
of implementations of vastly different levels of complexity around the
world. The hints from the Thoughtworks experts was that having a few
sample deployments (e.g., small, medium, and big) against which we
developer/test/deploy will probably work best. There will still be work
for implementations to adopt changes, but hopefully we can help them (and
us) predict more accurately how much work it will take to upgrade.
Cheers,
-Burke
On Wed, Nov 21, 2012 at 12:34 PM, Mark Goodrich <mgoodrich@pih.org> wrote:
> Actually, I believe what Darius is suggesting *doesn't* imply a single
> release line, and therefore complicates backporting by requiring major
> fixes to be backported to half-dozen releases or so.
>
> Unfortunately, I don't think we can get away from maintaining stable
> release branches that only get bug fixes backported for the reasons Rowen
> said... this is frustrating, and slows development, but I don't see an easy
> way around it because of the nature of OpenMRS and it's use. It would be
> interesting to hear from other implementers (cc'ing the implementers list),
> but I'm sure that the PIH-Rwanda team would echo Rowen's points.
>
> To Mike's idea of allow features that don't introduce backwards
> incompatibilities into maintenance releases... although we can gauge pretty
> well the risk of a new feature, we can never guarantee a feature won't
> introduce some kind of backwards incompatibility, considering the multitude
> of users we have using the system with various module configurations.
>
> Note that the idea of making the master branch releasable at any time
> doesn't mean we have to do three releases a quarter... it just allows us to
> do ad hoc releases if enough implementers are clamouring for new features
> that have been added to the master branch. For instance, if we had been
> following that model now, it's pretty likely that PIH would have planned to
> push out a 1.10 in conjunction with our Mirebalais hospital opening. This
> would have allowed us to contribute more to core over the past few months.
> (It also would have allowed us to skip having to the backport the order
> features we are adding to 1.9.x).
>
> Mark
>
>
>
>
>
> On 11/21/2012 11:55 AM, Rowan Seymour wrote:
>
> I see the Chrome kind of versioning/releasing working for a browser
> because
>
> 1. There are very few reasons a user wouldn't always want to upgrade
> (i.e. no backwards incompatibility issues)
> 2. There's only a small risk if things go wrong (i.e. nobody dies if
> your browser doesn't work 100%)
> 3. It's easy to continually upgrade as you're implicitly online and
> upgrades are relatively small patches (means #2 can be resolved quickly)
>
> Realistically in OpenMRS land we have to support enterprise scale
> deployments, with varying degrees of upgradability... so we've gotten stuck
> on the OS kind of versioning/releasing.
>
> In Rwanda we're about to embark on large scale upgrade from 1.6 to 1.9
> which I know that others found pretty painful due to due data model
> changes. Once we have OpenMRS deployed nationwide, that's going to be the
> sort of thing that can only be done every couple of years. Maintenance
> upgrades however, have usually proved painless - switch out the WAR and
> you're good to go.
>
> I'm not sure I understand how we can continue providing maintenance
> updates whilst ditching the backport model.
>
> -Rowan
>
> On 21 November 2012 18:38, Michael Seaton <mseaton@pih.org> wrote:
>
>> Darius,
>>
>> I like where you are going with all of this, and would love to see it
>> possible to evolve in this way.
>>
>> Historically, we have been pretty consistent with introducing some sort
>> of major backwards incompatibility in every major release we have done.
>> 1.10 will be no different from what I can tell with the Order changes. I
>> think this tendency will make it more difficult to achieve what you are
>> hoping for.
>>
>> Perhaps a less drastic change to our processes would be just to change
>> what is and isn't applied to our minor releases (eg. the 1.9.x line). If
>> we said that any new, complete feature that doesn't introduce any backwards
>> incompatibilities, or any major user interface changes, is a valid
>> candidate for applying to "maintenance" branches, then this may allow us to
>> achieve the bulk of what you are looking for, with less major disruption to
>> our standard way of working.
>>
>> Thoughts?
>> Mike
>>
>>
>>
>>
>> On 11/21/2012 11:26 AM, Michael Downey wrote:
>>
>> On Wed, Nov 21, 2012 at 11:22 AM, Darius Jazayeri <darius@openmrs.org>wrote:
>>
>>> How aboutFirefox/Chrome-like version numbering? OpenMRS 1.10, 1.11,
>>> 1.12, all in one quarter. :-) Not sure how we'd do this without making
>>> backporting of bugfixes be a huge pain though...
>>>
>>
>> Of course, what you didn't mention here is that such version strategies
>> imply one single line of releases, where the subsequent release is the
>> patch for the previous, and backporting doesn't really exist.
>>
>> Michael
>> --
>> OpenMRS Developers: http://go.openmrs.org/dev
>> Post: dev@openmrs.org
>> Unsubscribe: dev+unsubscribe@openmrs.org
>> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>>
>>
>>
>>
>> --
>> OpenMRS Developers: http://go.openmrs.org/dev
>> Post: dev@openmrs.org
>> Unsubscribe: dev+unsubscribe@openmrs.org
>> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>>
>>
>>
>
>
>
> --
> *Rowan Seymour*
> tel: +250 783835665
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
>
>
>
> --
> OpenMRS Implementers: http://go.openmrs.org/implementers
> Post: implementers@openmrs.org
> Unsubscribe: implementers+unsubscribe@openmrs.org
>
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
>
>
--
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org
Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
[Attachment #3 (text/html)]
We need a compromise between getting releases out quickly and being realistic about \
what our implementers & devs can handle. There are advantages to having our \
single-threaded approach (most working going to master + three supported minor \
versions). A more complicated model would probably create more pain than benefit. \
Perhaps some combination of the ideas mentioned would help:<div>
<br><div><b>Lower threshhold for a minor release when strategic priorities, feature \
set, and developer cycles make it desirable & possible</b><br><i>Example: 1.10 \
released sooner with less than previously planned, but with a few changes needed by \
the Mirebalais project</i><br>
<br></div><div><b>Increased effort to keep master releasable</b><br><i>Example: \
half-completed work is not pushed into master; more effort to code long-running \
features in a way in which they can be "released" in silent chunks</i><br>
<br><b>Allow for backporting backwards-compatible "features" when \
needed</b></div><div><i>Example: a "1.10" feature needed by implementations \
running 1.8.x that is backwards-compatible could be backported</i><br>
<br><b>Easier upgrade path for implementations</b></div><div><i>Example: Continue \
working on ways to reduce the pain for implementations to upgrade (e.g., refactor \
modules to participate in the release testing process, consider impact on \
implementations when designing/organizing changesets, etc.)</i><br>
<br><div class="gmail_quote">Have an extra release here or there when it's \
strategically useful shouldn't be a big deal. While upgrading can be a big deal \
for larger implementations, it's not significantly different to upgrade one minor \
version than it is to jump several minor versions at once (in fact, that's what \
most the bigger implementations have been doing).</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I doubt that the highest \
level of continuous delivery (the ability to deploy a release with any change) is \
attainable for OpenMRS with hundreds of implementations of vastly different levels of \
complexity around the world. The hints from the Thoughtworks experts was that having \
a few sample deployments (e.g., small, medium, and big) against which we \
developer/test/deploy will probably work best. There will still be work for \
implementations to adopt changes, but hopefully we can help them (and us) predict \
more accurately how much work it will take to upgrade.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div \
class="gmail_quote"><br></div><div class="gmail_quote">-Burke</div><div \
class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Nov 21, 2012 at 12:34 \
PM, Mark Goodrich <span dir="ltr"><<a href="mailto:mgoodrich@pih.org" \
target="_blank">mgoodrich@pih.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Actually, I believe what Darius is
suggesting *doesn't* imply a single release line, and therefore
complicates backporting by requiring major fixes to be backported
to half-dozen releases or so.<br>
<br>
Unfortunately, I don't think we can get away from maintaining
stable release branches that only get bug fixes backported for the
reasons Rowen said... this is frustrating, and slows development,
but I don't see an easy way around it because of the nature of
OpenMRS and it's use. It would be interesting to hear from other
implementers (cc'ing the implementers list), but I'm sure that the
PIH-Rwanda team would echo Rowen's points.<br>
<br>
To Mike's idea of allow features that don't introduce backwards
incompatibilities into maintenance releases... although we can
gauge pretty well the risk of a new feature, we can never
guarantee a feature won't introduce some kind of backwards
incompatibility, considering the multitude of users we have using
the system with various module configurations.<br>
<br>
Note that the idea of making the master branch releasable at any
time doesn't mean we have to do three releases a quarter... it
just allows us to do ad hoc releases if enough implementers are
clamouring for new features that have been added to the master
branch. For instance, if we had been following that model now,
it's pretty likely that PIH would have planned to push out a 1.10
in conjunction with our Mirebalais hospital opening. This would
have allowed us to contribute more to core over the past few
months. (It also would have allowed us to skip having to the
backport the order features we are adding to 1.9.x).<br>
<br>
Mark<div><div class="h5"><br>
<br>
<br>
<br>
<br>
On 11/21/2012 11:55 AM, Rowan Seymour wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
I see the Chrome kind of versioning/releasing working for a
browser because
<div>
<ol>
<li>There are very few reasons a user wouldn't always want to
upgrade (i.e. no backwards incompatibility issues)</li>
<li>There's only a small risk if things go wrong (i.e. nobody
dies if your browser doesn't work 100%)</li>
<li>It's easy to continually upgrade as you're implicitly
online and upgrades are relatively small patches (means #2
can be resolved quickly)</li>
</ol>
<div>Realistically in OpenMRS land we have to support enterprise
scale deployments, with varying degrees of upgradability... so
we've gotten stuck on the OS kind of versioning/releasing. </div>
<div><br>
</div>
<div>In Rwanda we're about to embark on large scale upgrade from
1.6 to 1.9 which I know that others found pretty painful due
to due data model changes. Once we have OpenMRS deployed
nationwide, that's going to be the sort of thing that can only
be done every couple of years. Maintenance upgrades however,
have usually proved painless - switch out the WAR and you're
good to go.</div>
<div><br>
</div>
<div>I'm not sure I understand how we can continue providing
maintenance updates whilst ditching the backport model.</div>
<div><br>
</div>
<div>-Rowan</div>
</div>
<br>
<div class="gmail_quote">On 21 November 2012 18:38, Michael Seaton
<span dir="ltr"><<a href="mailto:mseaton@pih.org" \
target="_blank">mseaton@pih.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> Darius,<br>
<br>
I like where you are going with all of this, and would love
to see it possible to evolve in this way.<br>
<br>
Historically, we have been pretty consistent with
introducing some sort of major backwards incompatibility in
every major release we have done. 1.10 will be no different
from what I can tell with the Order changes. I think this
tendency will make it more difficult to achieve what you are
hoping for.<br>
<br>
Perhaps a less drastic change to our processes would be just
to change what is and isn't applied to our minor releases
(eg. the 1.9.x line). If we said that any new, complete
feature that doesn't introduce any backwards
incompatibilities, or any major user interface changes, is a
valid candidate for applying to "maintenance" branches, then
this may allow us to achieve the bulk of what you are
looking for, with less major disruption to our standard way
of working.<br>
<br>
Thoughts?<br>
Mike
<div>
<div><br>
<br>
<br>
<br>
<div>On 11/21/2012 11:26 AM, Michael Downey wrote:<br>
</div>
<blockquote type="cite">
<div class="gmail_extra">On Wed, Nov 21, 2012 at 11:22
AM, Darius Jazayeri <span dir="ltr"><<a \
href="mailto:darius@openmrs.org" target="_blank">darius@openmrs.org</a>></span> \
wrote:<br> <div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>How aboutFirefox/Chrome-like \
version numbering? OpenMRS 1.10, 1.11, 1.12, all in
one quarter. :-) Not sure how we'd do this
without making backporting of bugfixes be a
huge pain though...</div>
</blockquote>
</div>
<br>
Of course, what you didn't mention here is that such
version strategies imply one single line of
releases, where the subsequent release is the patch
for the previous, and backporting doesn't really
exist.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Michael</div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
<br>
</div>
</div>
</div>
<div>
<div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a href="https://id.openmrs.org/" \
target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<b>Rowan Seymour</b><br>
tel: <a href="tel:%2B250%20783835665" value="+250783835665" \
target="_blank">+250 783835665</a><br> <br>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a href="https://id.openmrs.org/" \
target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
<br>
</div></div></div><span class="HOEnZb"><font color="#888888">
<p></p>
-- <br>
OpenMRS Implementers: <a href="http://go.openmrs.org/implementers" \
target="_blank">http://go.openmrs.org/implementers</a><br>
Post: <a href="mailto:implementers@openmrs.org" \
target="_blank">implementers@openmrs.org</a><br>
Unsubscribe: <a href="mailto:implementers%2Bunsubscribe@openmrs.org" \
target="_blank">implementers+unsubscribe@openmrs.org</a></font></span><div \
class="HOEnZb"><div class="h5"><br> Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br />
Post: dev@openmrs.org<br />
Unsubscribe: dev+unsubscribe@openmrs.org<br />
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/">https://id.openmrs.org/</a><br /> <br />
<br />
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic