[dev] Branches (again), Horde 4.1/5, recent IMAP changes

[Jan Schneider]

Hi,

I originally wanted to sum this up after all October releases are  
finished, but the recent IMAP (mailbox) changes made this somewhat  
higher priority.

Even though there are still some complaints, I think the switch to  
PEAR based releases was a great overall success. With a whopping 780  
(seven hundred and eighty!) package releases since we started the new  
PEAR server, we brought the paradigm of "release early, release often"  
to new heights, at least for Horde's standards. That, and the implicit  
dependency management makes me never want to go back.

But that's not the only thing we changed for Horde 4, we also intended  
to set new rules for release management  
(http://wiki.horde.org/Doc/Dev/ReleaseCycle) and branch management  
(http://wiki.horde.org/Doc/Dev/Branches). This is the area where we  
still need to improve.

We are currently in our 2nd release cycle since we released Horde 4,  
and everybody noticed by now that there is no Horde 4.1 in the works,  
let alone Horde 5. The reason is that we simply didn't have any new  
features or larger changes in our stable code base that hadn't been  
released yet anyway. That's why we focused on releasing the "missing  
bits" during this release cycle, i.e. the until now unreleased  
applications that had to be ported to Horde 4.

The reason for the lack of new features is that we kept adding new  
stuff to the master branch, i.e. to the stable branch, and still  
shuffled things around with new stable releases. I let this happen,  
despite this being against the release/branch rules, because I felt  
like there still were some teething troubles with our young Horde 4  
release (and Michael even explicitly expressed that he considered our  
stable release too early at one point) We also had some important  
things missing originally, that shouldn't had to wait another half a  
year. But at the same time I was intent to get an agreement to more  
strictly enforce these rules once the 2nd release cycle is over.
Because the flip-side of the coin is that (even though some of those  
changes in stable releases were necessary to fix bugs), the "stable"  
releases were much less stable than they should have been. Too often  
some of those larger changes caused intermediate regressions.  
Fortunately this didn't have such a high impact, thanks to our new  
release model (see above). I still think we should stop this now  
though. People should not be prepared to experience regressions due to  
code restructuring (like the mailbox encoding in IMP), notable UI  
changes (like in dynamic Kronolith) or new features suddenly popping  
up (like in - everywhere), while they update within a minor version.  
Such changes need more testing through RCs (yeah, I know, they won't  
be tested properly anyway, but that's a different story), and with  
piling them up for the next minor version, we actually *have* some  
minor version to release.

So, I urge everyone to read the wiki pages linked above again. If  
everyone is still fine with that direction, then let's all agree to  
enforce these rules from now on.

Back to my original impetus for this write-up. I wanted to restart  
this discussion after the current release cycle because 1) we would  
have half a year starting now to pile up new features/changes for a  
potential Horde 4.1 (or even Horde 5) release next April, which would  
match the originally planned release cycle length, and 2) I felt like  
our commits had settled a bit during the last few weeks (though this  
could also be caused by a stronger focus on the unreleased  
applications).
Thus the recent Horde_Imap_Client_Mailbox changes make me very strong  
headaches. This is exactly the kind of changes that has potential of  
causing more trouble than solving problems (for a bug fix release,  
that is). It introduces new dependencies, touches large parts of  
important code in IMP, and even converts existing user preferences.  
This is unacceptable for a simple bug fix release IMO. I *strongly*  
suggest to revert this on master, and re-apply it to the develop  
branch, so that it gets more and longer testing and won't be released  
before a IMP 5.1 RC.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/