[dev] [commits] Horde-Hatchery branch master updated. 32b8d7d18cb8987b1235005df6567d4d37e87950

[Jan Schneider]

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

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>>>> My suggestion is more along the lines of: for each system task  
>>>>> that needs to happen once per user, store the revision number of  
>>>>> the system tasks in their preferences (instead of storing class  
>>>>> names). So we start at revision 1. Each change gets a new  
>>>>> revision number (changes made together get the same revision  
>>>>> number). We update prefs.php.dist so that the default value is  
>>>>> always current (or we could have a special call that returns the  
>>>>> current level).
>>>>>
>>>>> Then on login, we get the user's current level, see if there are  
>>>>> any tasks after that, and run them.
>>>>
>>>> This seems like it is adding too much complexity in the  
>>>> logintasks.  Additionally, this requires us to load/parse the  
>>>> SystemTask every time a user logs in.  The present method doesn't  
>>>> require this.
>>>>
>>>> I still think that a command-line script is the preferred  
>>>> solution (it is written and currently lives in  
>>>> horde-support/maintainer-tools).  Upgrades are not all that  
>>>> common, and not that many people are running dev code, so this  
>>>> seems more appropriate.  And on the plus side: upgrading still  
>>>> becomes much easier because of having to find/run the appropriate  
>>>> script, we only need to do:
>>>>
>>>> cd [hordebase]
>>>> php horde-run-task.php -a [app] -t [taskname] -u [username]
>>>>
>>>> anytime an upgrade is announced.
>>>
>>> I don't think upgrades are as uncommon as you think, if you take  
>>> all applications into account. And maybe more people would run dev  
>>> code (and get into helping development) if we made it easier.  
>>> Keeping accounts/prefs/data up to date is one way to do this.
>>
>> I still personally think that the whole 'incremental' counting is  
>> much kludgier than running command line scripts.  And again - it  
>> adds a whole bunch of overhead to every user's login whether they  
>> use developmental code or not.  I am not a big fan of requiring  
>> 99.9% of users to run code that will *never* be needed just for the  
>> .1% of users that may need it.
>>
>>> A command line script just feels kludgy to me. A general solution  
>>> that works for developers and end users regardless seems much more  
>>> elegant to me and worth it in the long run.
>>
>> But we've been doing things command-line for years.  LoginTasks  
>> were not designed to fully replace upgrade tasks.
>
> Okay - any other opinions here? If no one else feels strongly about  
> the side I've been proposing, I'll agree to go with command line  
> scripts for now.

I agree with Michael. I really prefer automatic upgrade tasks for new  
releases, to make life easier for administrators. But for development  
versions, command line scripts have been working fine in the past.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090818/b0364bf2/attachment.bin>