[commits] [Wiki] changed: Draft Release Cycle

[Chuck Hagenbuch]

chuck  Mon, 31 Jan 2011 00:37:12 -0500

Modified page: http://wiki.horde.org/Draft+Release+Cycle
New Revision:  1.3
Change log:  add rlang

@@ -37,4 +37,23 @@
  The second branch only exists so we can run some tests on it to find  
if anything is broken, and to allow us a fastest integration when new  
stable releases are done by Horde. But then again, this is in no way  
decided. We might also don't merge for the entire 6 months, and then  
take some days to make it.

  As developers working with latest code, we also have some trouble  
finding information on what's going on and what's planned. Ok every  
app has it own roadmap, but that's it.
  Im sure Horde developers have meetings somehow, where you decide  
what and how you will do things. It would be great to share with the  
community that thoughts , so we can understand a bit better where we  
are going to.
+
++++ Ralf Lang
+
+As a mostly external developer, I want to add my thoughts on BC  
breaking. I strongly advocate BC breaks when needed (the type of thing  
I expect from H4.x
+-> H5 after maybe a year or two) and complete redesigns like H3->H4  
only when you feel the old patterns really won't work any more.
+
+The last 1-2 years asked difficult decisions for me, what's the way to go.
+
+I had some non-public applications done and now I picked up eleusis  
in official horde repos.
+
+For most of the time, H4 (git) was no viable option. Moving too fast,  
no guarantees, no release in sight, virtually no documentation or  
people to ask. On the other hand, the H3 way to do things asked a  
php4-ish approach and sometimes libraries/api's which the Horde Core  
developers themselves tried to replace already. I tricked myself  
around, using the latest H3 sometimes with components pulled from   
cvs-head and /incubator/.
+
+I'm not complaining. The result of H4 development has been a big leap  
forward, both API wise and in applications. Also dropping PHP4 has  
helped a lot. On the other hand, I'd be glad to see more gradual  
changes even when breaking BC.
+
+I don't think customers would want to pay a migration of any custom  
app from H3 to H4 while keeping H3 as a platform is definately a dead  
end.
+
+Turning that to open source community development: I think most of  
the improvement patches geared to H3 versions which still await review  
would need more than just cosmetic changes to work in H4. Developing  
for the trash can doesn't attract casual committers. Yes, that's a bit  
harsh and shouldn't be taken too seriously. Just my thoughts.
+
+I'm happy to see H4 coming and I'm waiting to package it for openSUSE 12. ;-)