[dev] [commits] Horde-Hatchery branch master updated. 746dc9af33a4558e24c79c6812dcc02e9684872b

Chuck Hagenbuch chuck at horde.org
Mon Jan 4 19:54:18 UTC 2010


Quoting Michael Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> commit 6bb67b4f489bb28586deb42f8d30225430e07721
>>>> Author: Jan Schneider <jan at horde.org>
>>>> Date:   Wed Dec 23 15:33:26 2009 +0100
>>>>
>>>>  Re-add lost upgrade script.
>>>>
>>>> ingo/scripts/upgrades/convert_imp_filters.php |  272  
>>>> +++++++++++++++++++++++++
>>>> 1 files changed, 272 insertions(+), 0 deletions(-)
>>>> create mode 100755 ingo/scripts/upgrades/convert_imp_filters.php
>>>>
>>>> http://git.horde.org/co.php/ingo/scripts/upgrades/convert_imp_filters.php?rt=horde-hatchery&r=6bb67b4f489bb28586deb42f8d30225430e07721
>>>
>>> Any particular reason for this?  This was intentionally removed.   
>>> IMHO, if someone is really converting from Horde 2 apps, the  
>>> proper and desired route should be to upgrade to Horde 3 first and  
>>> then Horde 4.  No need to maintain scripts in Horde 4 for  
>>> long-deprecated data structures.
>>
>> No, we never required users to upgrade to an intermediate version,  
>> and we shouldn't start doing it. I don't see a reason why we should  
>> either, beside we being too lazy to keep upgrade scripts working.
>
> For minor point version upgrades, I agree, but for anything  
> approaching a major version upgrade, I think I agree with Michael on  
> this one. I know in the past, some of our UPGRADING instructions  
> explicitly stated that if you were upgrading from an earlier version  
> then x.y, then you must first upgrade to x.y before upgrading to z.   
> IMO, this makes sense, since upgrade scripts are usually  
> touching/migrating data structures. I think that besides the time  
> and energy to maintain all upgrade scripts going forward, there is  
> also the issue of consistency. It could also lead to confusion as to  
> which version of the upgrade script someone is running.
>
> If we do end up agreeing on keeping the upgrade scripts up-to-date,  
> then I think we need to both set a limit on how many versions back  
> to maintain them, like one major release, or to rename the upgrade  
> scripts to make it clearer that they are for going directly from  
> Horde 2 -> Horde 4 or Horde 2 -> Horde 3 etc...

Agreed...

-chuck


More information about the dev mailing list