On Sat, 2010-04-24 at 07:51 -0400, Tony Graziano wrote:
> Currently it is possible to upgrade (via yum or gui) from an unstable
> version (4.01 or 4.03) to 4.20, without "stopping" in between.
First - those are not valid numbers - 4.0.1 is the number, not 4.01 -
don't drop the second dot.
Second - 4.0.x are stable versions (but 4.0.1 and 4.0.2 are old and
should have been upgraded to 4.0.4 quite a while ago).
> I feel there should be a mechanism in place to prevent this unless
> manually overridden.
>
>
> For example, if running a 4.0x version prior to 4.0.4 (4.0.0,
> 4.0.1,4.0.2,4.0.3), upgrading to 4.2 would most likely result in a
> broken system, because an intermediate update did not take place and
> the schema did not get extended.
>
>
> Does it make sense to have an upgrade run "database upgrades" of
> anything in between automatically and allow the upgrade to happen or
> does it make more sense to make the user stop at each version along
> the way one by one?
>
>
> Is there a better way to approach this or is something already
> underway I didn't see?
The database upgrades are designed to be cumulative. In theory, it
should be possible to upgrade from any stable release directly to any
other stable release (note: upgrade should work - downgrade is not meant
to).
In theory there is no difference between theory and practice,
but in practice sometimes there is.
It should not surprise anyone to hear that upgrading from the most
recent stable release to any new release is the one that gets the most
testing, so it's always possible that some idiosyncratic issue could
arise.
One of the differences between a paid-for support system and the free
one you get with this and other open source projects is that we really
can't afford to provide the same high level of support for old versions.
It is best to keep up with fix releases.
If you can document (before and after snapshots - for the before at
least no logs are needed) a specific upgrade problem in any
stable-to-stable upgrade, that will be treated as a bug and if possible
addressed.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
