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

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck at horde.org>:

> 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...

3:1, I guess I'm convinced ;)

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/