[dev] [commits] Horde branch master updated. 760524934f11365acac54b36a4ced40996062ebe

Tue Oct 22 08:18:04 UTC 2013

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>>> e6a7d00 Released Horde_Socket_Client-1.0.0
>>>
>>> I thought we made it clear that using namespaces in Horde 5 is NOT  
>>> acceptable!? Why did you ignore what we said?
>>
>> This was an oversight.  While I disagree that anything was formally  
>> decided, Horde_Smtp had a critical issue -- albeit rare -- that  
>> needed to be fixed.  And there was no reliable way to do this  
>> without releasing both since we don't have separate git repos for  
>> libraries (git revert-ish like behavior is not acceptable).  I did  
>> not think of namespacing issues when releasing Socket_Client.  But  
>> it was the correct decision - the critical bug needed to be fixed.
>>
>> This doesn't affect anybody though.  I believe one of the arguments  
>> against namespacing was "people won't know which form of  
>> namespacing to use."  Huh?  That argument makes zero sense.  Either  
>> that or I am a terrible coder because I need to look at the  
>> documentation before writing a function call when apparently  
>> everybody else somehow magically knows how to call Socket_Client's  
>> constructor which, again, didn't exist until a week ago, and knows  
>> what sort of Exceptions it may return.
>
> This argument makes no sense to me. Yes, learning about a new  
> library is a must before using it - but that has nothing to do with  
> the fact that ALL of our Horde 5.x libraries do not use namespaces.  
> Regardless if I have to look up how to call some method in a new  
> library, I still need to remember it's a namespaced library. There  
> is a difference in knowing what Horde_Foo::doSomeStuff() *does* vs  
> having to rememember that Horde_Foo is really Horde/Foo while  
> Horde_Bar:: is, well, Horde_Bar::.  Having some libraries namespaced  
> and some not completely goes against the idea of having formal  
> coding standards.
>
> I think of it this way. If I were in a bookstore (remember those?),  
> looking at the computer section, would I see a single book about  
> coding with the horde framework libraries, or would I see dozens of  
> books, one for each library we have? Even taking the more general  
> argument about H5/H6 libraries out of the discussion, you have to  
> agree that if you were reading a book about coding with the Horde  
> Framework it would seem a bit odd that only 1 or 2 libraries are  
> namespaced, wouldn't you?
>
>> I agree that you can't change EXISTING code.  But any argument  
>> about a developer not being aware which namespacing method to use  
>> for an entirely new library is completely disingenuous and simply a  
>> non-starter for me.  So we can release a new major version of the  
>> package just to change the namespacing rules, but that seems like a  
>> waste of time for no gain.
>
> This would be true (maybe) if the package was not part of a larger  
> ecosystem that comes with certain expectations, and it still  
> wouldn't solve the issue. It's not the *package* that needs to have  
> the major version changed, it's *all* the packages. They may be  
> independent packages, but they are still part of the Horde ecosystem  
> and ALL of them should then be namespaced.
>
>> Whether we want to do it or not is still an open question.  I'm not  
>> convinced myself it is the correct way to go.
>
> Personally, I don't see this as an open question. Horde 5.x code  
> should NOT be namespaced. Period.
>
>> But **PLEASE** stop using "Horde 5 library" as a justification  
>> here.  THERE IS NO SUCH THING AS A HORDE 5 LIBRARY (with the  
>> exception of Horde_Core)!!  I thought that was made clear long ago.
>
> There *absolutely* is such a thing as a Horde 5 library. It's a  
> library that must maintain BC with any Horde 5.x application. Adding  
> libraries at will with different coding standards, incompatible APIs  
> etc... AND USING THEM IN HORDE 5.x is not acceptable. If you want to  
> call it something else, go ahead, it's just semantics, but the  
> bottom line is all of the released framework libraries must be BC  
> with each other and with our released applications, within the same  
> major version number.
>
>> Socket_Client has absolutely NOTHING to do with H5.  Nothing.
>
> So, Socket_Client is not going to be used anywhere in H5 code? If  
> somebody wants to develop an application that would fit into a Horde  
> 5 application stack, they would not be able to use Socket_Client, or  
> Horde_Text_Filter or... ? That's what your statement above means to  
> me.
>
>> Horde_Text_Filter has absolutely NOTHING to do with H5.  Nothing.
>> Horde_Support has absolutely NOTHING to do with H5.  Nothing.
>> etc.
>
>> Just because they all live together in our git repo doesn't change  
>> any of this. This was all discussed long ago on the list.
>
> And we had the same disagreement then as well.
>
> I understand what you are saying, but even if the libraries are not  
> "part of Horde 5" they still must follow at the very least the same  
> coding standards and general requirements. To me, there is no  
> difference in what you want to do vs making one library require PHP  
> 6.0 (or whatever) and the rest require 5.4 and use that library  
> within a Core application. Library code that is used in any horde  
> application must maintain the same CS and overall requirements.
>
>> And I'll agree that the namespace decision might fall under the  
>> rubric of general Horde coding standards.  But this decision has  
>> nothing to do what we've done in other "H5 libraries", since that  
>> term - outside of Horde_Core - has no meaning.
>
> Sorry. Still disagree here. If we use Horde_Foo version 2.0 in Horde  
> X release, that library, to me, is a Horde X library - meaning any  
> code in that library must comply with Horde X coding standards  
> and/or other general system requirements. We couldn't release BC  
> breaking Horde_Foo version 3.0 and use it in a Horde X application,  
> so why shouldn't we treat Horde_Foo 2.0 as a "Horde X" application  
> in this context?
>
> Do you know of any other project providing stand alone libraries  
> that mix and match things like this in their stable code? Not being  
> a smartass here, I honestly don't the answer to this.
>
>> We absolutely must not be releasing new major versions of libraries  
>> for H6.  Socket_Client is absolutely not going to be bumped to 2.0  
>> for H6.  That's because Socket_Client has absolutely nothing to do  
>> with H6.
>
> Then maybe it shouldn't have been released until Horde 6 if you  
> insist on keeping it namespaced.
>
> Regardless, this is what we did going from Horde 4 -> 5 and is what  
> I was expecting going from H5 -> H6. Though I don't care as much  
> about *this* point as I do about the others. I.e., I don't care if  
> we still use Socket_Client version 1.x in Horde 6 code assuming the  
> API remains BC with Horde 5, and we don't bump it to 2.0 during the  
> Horde 6 release cycle.
>
>> If there continues to be this belief that libraries are somehow  
>> tied to applications, that is a core, fundamental issue I have that  
>> is not going to change and makes me concerned going forward.

And we even have all this formalized in our release rules.

 From http://wiki.horde.org/Doc/Dev/ReleaseCycle:
We will have sychronized releases of all application and framework  
components. If it's going to be a minor version release, only the  
modules that actually had any changes will be released. For major  
versions, all modules will be relased.

This doesn't necessarily mean that we aren't allowed to bump a major  
version of a library inbetween major releases of Horde. If for example  
Horde_Imap_Client 3.0 would have been ready for IMP 6.2, we could  
release it, and make it a requirement in IMP. The problem is, and  
that's a good example of the general problem of decoupling libraries  
from Horde major versions: Since 3.0 is API incompatible to 2.x, *all*  
apps and libraries of Horde_Imap_Client would have to be updated to  
the new API. Otherwise users of, say IMP and Horde_ActiveSync cannot  
upgrade at all.

Besides the technical reasons for keeping releases synchronized, there  
is another aspect: marketing. Horde 5 is keyword, as well as an eco  
system. Like Symfony2 is. If we want to encourage and propagate usage  
of Horde libraries, we must not get developers into dependency hell or  
having to learn different APIs or coding standards.

The release of Horde_Socket is spilt milk now though. I'm not a friend  
of pulling releases, and I don't think releasing 2.0 without  
namespace, just to release 3.0 with namespaces again, once we  
namespace all libraries, is a good option either.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/