[dev] Horde release cycle
Gonçalo Queirós
goncalo.queiros at portugalmail.net
Sun Jan 30 01:39:32 UTC 2011
Em 26-01-2011 14:27, Ralf Lang escreveu:
>> All of this effort is only important if Horde wants to attract external
>> developers. I see that as a hidden asset of the Horde project itself --
>> there are lots of other groupware packages out there but Horde is better
>> suited than most for 3rd parties who want to integrate tightly into our
>> apps. This may not be our primary objective. If we need to be more
>> concerned with Groupware features than API stability maybe we do not put
>> as much effort into our BC promise. It's a matter of priorities.
>>
>>
>> /BAK/
> 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. ;-)
>
> --
> Ralf Lang
> Linux Consultant / Developer
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi there list.
In my company we've been developing with Horde 4 for like one and half
year. We have our own branch, where we change some Horde apps and Core,
and some apps developed in-house, and we merge Horde code from time to time.
The gap between merges is usually one week (the train moves fast :-),
but when we need to prepare a new release (yes we already have it in
production), we stop merging with Horde since its development code, and
we need some time to make tests etc...
Having 6 month releases would give us developers, the confidence that at
least twice a year the code is in a stable state, and ready for production.
We didn't decide yet how we are going to work after H4 is released, but
it also depends on how Horde plans releases, but i think we will have a
stable branch that will only receive Horde bug-fixes and security
updates plus in-house development, and a second branch, that would have
all the previous branch code, plus weekly merges with Horde.
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.
Thanks
Gonçalo Queirós
More information about the dev
mailing list