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

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> 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.

So here's an example where I don't believe our current branching model  
falls apart.

I have code that adds the ability for portal blocks to only load the  
CSS necessary for the portals themselves, rather than the entire  
application's CSS load.  (For simplicity, all of an application's CSS  
is stored in a single file rather than a CSS file for each portal  
block).

The code to do this in Horde/Core is trivial - no more than 30 lines.   
It does add a dependency on a new method in  
Horde_Core_Block_Layout_View, but this could be easily worked around  
by bumping the minimum dependency in horde.  I've also finished the  
code that converts imp, ingo, and turba to this new feature.  Old  
applications are not affected, since if a 'block' subdirectory is not  
found in a theme it defaults back to loading the entire CSS.

Given the recent discussion on code changes - I personally feel this  
is not a serious enough change to have to wait until the next minor  
release.  Granted, this is not a bug fix but it is a pretty  
substantial performance gain (especially for IMP blocks, where the CSS  
is substantial).

However, assuming that this should wait until the next minor release,  
where should it go.  It can NOT go into the develop branch.  The  
necessary changelog entries and package dependencies are unknown as of  
this time, so this change can not be packaged into a single commit.   
Putting it into a topic branch is not very useful either - not only is  
there no indication anywhere that this needs to get merged for the  
next minor release, but having this code living in a random topic  
branch means 1) nobody is going to see/use/test it, and 2) there is no  
indication that this code will play nice with other changes when  
merged in the future (better to resolve conflicts now, when the code  
is fresh on the mind).

What is a proper solution for this?

michael

___________________________________
Michael Slusarz [slusarz at horde.org]