Re: Horde 6 vs. Horde 5.3

Hi Jan and Michael,

Am 24.09.2016 um 05:21 schrieb Michael J Rubinsky:
>> Another alternative would be to simply release what we currently have
>> with the version that we planned, and then aim for Horde 7.
>> That means we release Horde 6, IMP 7 et al. We don't *have* to break
>> BC to justify a major version bump, and we still *shouldn't* make too
>> many BC breaks to not delay the next release much more.
> 
> This may be the most sensible solution. The end result is the same -
> that is, the basic view is gone - but that's less of a surprise factor
> with a major release.

speaking of BC break, "framework/Horde_Text_Filter_Csstidy" is also
no longer available. Not that I'm missing it, I've just noticed it as
I'm doing a major upgrade to my local horde stack untouched since 2014.

Expect ActiveSync / Kolab torture testing the next two weeks.

>> What are the side-effects? Thing we promised for H6 would happen in H7
>> only. But that's just a name.
> 
> The only concern that comes to mind is what this would like like in the
> repository since we haven't split it yet. We have historically been only
> maintaining the framework in the master branch, but now having the
> possibility of at least small BC breaks, we will need to maintain
> framework in at least two branches now - maybe even three if we start
> any non-stable development pre split (the current FW_52, FW_6, master).
> Though, I guess this isn't that much different that what we would need
> to do for each individual repository once it's split anyway...

yep, it doesn't matter much if patches need to be ported
to a different branch or separate repo. Luckily git handles
multiple remotes in one tree with the blink of an eye.


As I plan to do extensive "user side" testing the next two weeks,
it might make sense to do a release only after the "QA phase".
But it's not my decision to make :)

Cheers,
Thomas

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]