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

* Your Email Address
* Spam protection	Enter the letters below: ._.. . __.. ..__ \| \| \|(__ \|_/ [__) _\|_\|__\|.__)\| \\|
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries