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

[Chuck Hagenbuch]

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.

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.

-chuck