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

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

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

I think I have to go with Michael/Jan on this one as well.


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin