[dev] Horde 5 was: Re: [commits] Horde branch develop updated. fa956a4d83a7227e2a5d47bfe87185854e151fbc

[Gunnar Wrobel]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> When we discussed the new release model for Horde 4, one of the  
>> important points was indeed that we don't want to fear breaking BC  
>> if we consider it necessary to go forward. I say we have reached  
>> this point, and instead of spending too much time in such  
>> discussions and causing frustrations, we should make the next  
>> release Horde 5.
>> I already considered to bring this up before this thread started,  
>> because if we really manage to get the new design in place for the  
>> next release, this would probably be a large enough change for the  
>> end users that it warrants and a new major version, even if we  
>> didn't break BC.
>>
>> If everyone could agree to this, let's go forward with Horde 5 (and  
>> let's quickly update any conference, paper, article applications  
>> that mentioned 4.1).
>
> Being the one who sort-of initiated this point, I probably should be  
> saying +1 with an exclamation mark.  But just a couple of thoughts:
>
> * The issue with me jumping major versions (despite Firefox/Chrome's  
> attempt at a paradigm shift) is that it suggests there are going to  
> be major changes to installation and config.  I don't believe that  
> is going to be the case.

Yes. I would say that was one major focus as well as a major success  
of Horde 4.0: Making upgrades rather simple so that we could release  
faster and the admins could upgrade faster. So there shouldn't be any  
changes there.

On the user side a major version change may sometimes be associated  
with grand changes on the surfaces. But as you mentioned there exist  
different paradigms out there and I think each project has to decide  
what model fits best.

Horde has been pretty strict concerning the versioning scheme and I  
think we all agreed we stick to semantic versioning  
(http://semver.org/ and http://wiki.horde.org/Doc/Dev/ReleaseCycle).  
There is *nothing* that mentions major changes to the configuration  
scheme or the installation procedure in the versioning document.

Horde is also a development framework and I believe we should keep  
sticking to semantic versioning. If this is not transparent on the  
user side we need to ensure we make this more obvious.

>  Most of the things that will be changing will be core-stuff;  
> looking at 4.1 (or 5.0) as an end-user, you are really not going to  
> notice a difference.

I do believe there will be quite some changes concerning the UI in March.

>
> Maybe this is just an educational thing.  But I wonder if some users  
> will be a bit hesitant to upgrade solely because they fear things  
> are going to break.

As mentioned above: I think the upgrade path is one thing that has  
seen significant improvements with 4.0. I repeat this over and over  
whenever I have the chance: The Horde installation may not be trivial  
but the updates are and I believe the latter is what counts. It  
doesn't hurt to repeat that the same is true even for major versions.

Cheers,

Gunnar

>
> * I would like to see a bit more clarification regarding what Horde  
> 5 means.  Because it is a bit confusing at the code level since it  
> really is no longer horde (the application) that is important, it is  
> Horde_Core (the package).  Not sure if we can, or should, do  
> anything about that for purposes of keeping things simple for the  
> customer.
>
> But while it is fresh on my mind, and so that I have a record of it,  
> thought I would lay down some elements on how to fix the whole  
> Registry init mess that led to this thread.  The way I see it, we  
> need the following:
>
> init(): Given the fact that people have been using this method  
> incorrectly, its probably best renamed to something like  
> bootstrap().  It's the minimum code necessary to allow the registry  
> to access the application framework (NOT the application data).   
> E.g. setting up factories.  This method is potentially called before  
> an application is authenticated, and possibly before the framework  
> is available.
>
> authenticateInit(): This is a method that is called ONCE per  
> session, when an application is authenticated to.
>
> init() (or onPush()?): This is a method that is called ONCE per page  
> load, when the application is first pushed onto the stack.  This is  
> where global application initialization can be done, although as a  
> practical matter things should be auto-loaded as needed to reduce  
> resources.
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de