[Tickets #10093] Re: Cannot create folder name with ampersand

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10093
------------------------------------------------------------------------------
  Ticket             | 10093
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | Cannot create folder name with ampersand
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 3. High
  Milestone          | 6
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2011-06-28 12:34) wrote:

>> 1. Why can't IMP 5.1 require a newer version of a specific package?
>> Isn't that part of the intent of the separate framework packages?
>
> This was my understanding/belief also.  A minor version bump is  
> intended to indicate that the basic framework is the same (i.e. no  
> major data/configuration changes), but that there may be some  
> substantial changes to the underlying system to fix limitations in  
> the previous version.

No, it's not that vague ("major" or "substantial" changes). The  
definition is clear. A minor version bump means that functionality has  
been added or an API has been *extended*. *Changing* the API requires  
a major version bump.

I could see us allowing to require a certain version of a dependency  
though. We already allow this for packages that haven't been released  
yet. But the important question is:

>> 2. Is the change to Horde_Imap_Client one that will break IMP 5.0, or
>> is it just that this bug won't be fixed without it?
>
> Right now, Horde_Imap_Client accepts either UTF-8 or UTF7-IMAP  
> strings for all mailbox parameters.  This needs to be changed to  
> Horde_Imap_Client accepting UTF-8 strings only (since it can not be  
> 100% reliably auto-detected).
>
> I am positive that IMP passes both types of strings to H_I_C  
> methods.  So this needs to be changed to UTF-8 only.  But this  
> change in IMP is worthless if there is not a corresponding change in  
> H_I_C - since we need to be calling a version of H_I_C that does not  
> do any auto-conversion.

So this would clearly be a BC break. And it won't only affect IMP, but  
also any 3rd party developers that use this library and depend on  
auto-conversion.

> There are other things that need to be fixed in H_I_C (allowing  
> multiple mailboxes to specified to search(); returning the list of  
> UIDs that were altered in store() instead of a boolean) that should  
> be done sooner rather than later.
>
>> 3. No matter how long we took on the release, we would have found
>> something like this.
>
> That is probably true - this is a bit broad of a statement on my  
> part.  But locking ourselves into an API, without the benefit of  
> broad-based, thorough testing, is a terrible thing.  This was the #1  
> failure of Horde 3 - we should not be supporting broken APIs for  
> (potentially) years simply because that happen to be the state of  
> things the second version x.0 came out.

We don't support them for potentially years, unless there isn't  
anything in the APIs that require BC breaking changes. If a BC break  
is necessary, we have to decide whether we want to have this into the  
next release (which would be a new major version then). Releases are  
done every half a year.

There is no easy solution for a buggy API design. Like Chuck said,  
this can always, and it's something you have to live with if you want  
to provide a stable and reliable release policy. And in this specific  
case, it can really only be fixed by changing the API. But then again,  
it's only still broken for very fringe use cases, and I doubt we will  
see a single bug report until the next major release with the improved  
auto-detection in place.