[dev] [commits] Horde branch FRAMEWORK_5_0 updated. 450bba25ab112a31ff062869971d780fd011f8f5

Tue Apr 16 23:46:11 UTC 2013

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>>
>>>> commit 70a25e2194fc5e790cebf3c18491d2a319b70395
>>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>>> Date:   Tue Apr 16 16:54:29 2013 -0400
>>>>
>>>>  Bug: 12185 Fix bad cherry-pick.
>>>>
>>>>  Horde_ActiveSync_Device is not present in FRAMEWORK_5_0
>>>>
>>>> framework/ActiveSync/lib/Horde/ActiveSync/Connector/Importer.php  
>>>> |    3 +--
>>>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>>>
>>>> http://git.horde.org/horde-git/-/commit/70a25e2194fc5e790cebf3c18491d2a319b70395
>>>
>>> My question is why are *ANY* framework commits being made to  
>>> FRAMEWORK_5_0 at this time.  This doesn't make sense.  Framework  
>>> code is not tied to 5.0 (or any other Horde version for that  
>>> matter).
>>
>> Sure it is. We are still doing synchronized releases for minor  
>> versions. I.e., new features for Horde 5.1. Bug fixes for  
>> functionality that exists in FRAMEWORK_5_0 are still being built  
>> from FRAMEWORK_5_0.
>
> That's absolutely not how it works though.  Under this reasoning,  
> there is no purpose to maintaining separately distributed libraries  
> since you want to tie certain versions to certain releases.

That's part of what http://wiki.horde.org/Doc/Dev/ReleaseCycle says  
though - that we will have coordinated minor releases. Plus, I'm not  
tying a framework release to a specific Horde version, I'm waiting to  
release a new piece of functionality in Horde_ActiveSync until new  
functionality in Horde 5.1 (which is required for the new AS  
functionality to work fully) is released. The new 2.4.0 version of  
ActiveSync should work fine with Horde 5.0.

>> The new features in the ActiveSync code (which will be in  
>> ActiveSync 2.4.0), while BC with Horde 5.0, still required  
>> substantial changes to the code base and deserve to go through the  
>> full release cycle of 5.1 before they are declared stable.
>
> But what does version 2.4 have to do with Horde 5.0?  How is it any  
> different than veersion 2.5? Or version 2.10?  Just because version  
> 2.4.x happened to be released concurrently with Horde 5.0.x doesn't  
> mean there is anything special about the combination of those two  
> branches.

Correct. Well, other than Horde can specify that it requires a  
specific minimum version of a package, but that's a different  
story...and in fact Horde 5.1 DOES require Horde_ActiveSync 2.4.0. I'm  
not saying that there is anything special about a combination of  
versions, other then to obtain the full feature set of one library, a  
specific version of Horde is required.

> If release version 2.5 is not stable enough for Horde 5.0, it sure  
> as heck isn't stable enough for Horde 5.1 either.

No, but how in the world am I going to know for sure if it doesn't go  
through the full release process? It's the same argument I was making  
regarding the recent CSS compression library change. This is what beta  
releases are for, especially for something as fragile as the  
ActiveSync protocol. Most of the issues I'm worried about are not  
things that can be can be caught by unit testing on my local machine,  
or even by testing with the dozen clients I have available. Most of  
the issues are due to, shall we say, "features" of clients. As is  
evidenced by the almost daily ActiveSync related problems that show up  
on the lists.
Finding these issues BEFORE stable release is better than after - and  
they can only be fully tested with Horde 5.1.

Maybe I have a different view of a how a minor release should be  
released. I see minor releases as requiring at LEAST a beta release  
before a stable release and this should include ALL new functionality.

> If you are not comfortable with the stability with a certain  
> framework package, you *must* branch the entire repo into a  
> different package.

Which is what we all did prior to merging with master, but with our  
current branching model we MUST merge these branches at some point  
before release and this is the in between state we are in right now.  
Obviously once the new packages are released there will be no need to  
make library commits to FRAMEWORK_5_0. These are things that, last  
week, would have gone into master and not into the 5_1 branches. I see  
no reason to not make this distinction now just because the branches  
are merged, but not yet released. I agree we still need discussion on  
our branching model, but that is a different discussion. We have to  
make commits based on what we have today.

> This is exactly what I had to do with several horde_imap_client  
> releases - I was uncertain about the stability, and wanted to  
> release point version bugfixes of the library.  But claiming that  
> 2.4 is somehow "connected" with FRAMEWORK_5_0 makes no sense.

No, but 5.1 requires 2.4.0...and the new functionality requires 5.1 to  
be used.

>> Put another way, I'm not going to release ActiveSync 2.4.0 as  
>> stable before it has been more widely tested, and I'm not going to  
>> hold up bug fixes for the current stable code because of this.

> We may not like it, but that's the reality of our current situation.  
>  Namely: there is no way to coherently produce "branches" of  
> framework packages.  That's exactly why I have been tremendously  
> vocal about moving off of our current repo layout for at least a  
> year now.

I would say the same thing, the current situation is not ideal, but  
it's what we currently have to work with. Therefore, since I want to  
release the new functionality as beta I need to commit bug fix  
releases to FRAMEWORK_5_0 while we are still in this before  
release/post-merge limbo.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20130416/1cd04acc/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130416/1cd04acc/attachment-0003.bin>