[dev] Horde 6 vs. Horde 5.3

Sat Sep 24 03:21:39 UTC 2016

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Ralf Lang <lang at b1-systems.de>:
>>>>>
>>>>>> Am 15.06.2016 um 19:23 schrieb Thomas Jarosch:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Wednesday, 15. June 2016 11:16:02 Michael J Rubinsky wrote:
>>>>>>>>> The flipside is, that:
>>>>>>>>> - Horde 6 will delay even further
>>>>>>>>> - we won't be able to do any refactoring, e.g. switching to  
>>>>>>>>> namespaces
>>>>>>>>> - we won't have a repository split that would make the libraries
>>>>>>>>> more attractive, e.g. by being available via composer/packagist and
>>>>>>>>> thus attracting external developers
>>>>>>>>> - we won't be able to do long-anticipated BC breaks that currently
>>>>>>>>> hinder some development
>>>>>>>>>
>>>>>>>>> The discussion is open.
>>>>>>> doing a "maintenance" release before Horde 6 is a good idea.
>>>>>>>
>>>>>>> As MJR mentioned, the removal of the basic view in IMP 7 is a  
>>>>>>> bit worrisome
>>>>>>> for a "point release". On the other hand, if the next release  
>>>>>>> would be Horde
>>>>>>> 6 and users were still using those views, they'll complain, too :)
>>>>>>> At least I'm using the minimal view, but hey, let's move forward.
>>>>>>>
>>>>>>> Could we branch off the IMP view changes
>>>>>>> or would that be too much git surgery?
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>> I may be wrong here - I think there can be an IMP 7 on top of Horde 5.3
>>>>>> - which would also support IMP 6 with basic views if you need to have
>>>>>> them. Not sure if the Horde 6 IMP would be IMP 7.1 or IMP 8 then.
>>>>>
>>>>> While I don't think there is any technical reason this can't be  
>>>>> done, historically we have always had coordinated major releases  
>>>>> - that is, the major version numbers were always increased  
>>>>> together across the applications and indicated a break in  
>>>>> backwards compatibility with the previous major version line.
>>>
>>> Having thought more about this today, I think this what we should  
>>> do. That is, having IMP released as 7.0, even though we "just"  
>>> release Horde 5.3. There's a technical reason too, because at  
>>> least for the groupware bundles we can enforce to keep on IMP 6  
>>> for Groupware 5.3. People won't accidentally lose the basic view  
>>> with a regular upgrade.
>>
>> I had suggested something similar and you had said that that was a  
>> "political solution to a technical problem" and that the current  
>> PEAR installer would probably update to the latest available anyway.
>>
>> https://lists.horde.org/archives/horde/Week-of-Mon-20160620/055833.html
>
> Indeed, if we release two Groupware versions and if the users aren't  
> careful, the PEAR installer will always update to the latest  
> version. In that case it would help if we lock IMP to version 6.2 in  
> a Groupware 5.3 release. But that would happen with any major  
> release anyway. There is no way to confirm a major version upgrade  
> or limit upgrades to minor/bugfix versions only, in the PEAR  
> installer.
>
> PEAR as a repository was working around this by changing the package  
> name, so for example horde-5.2.xx would become horde6-6.0.0. The  
> <extends> tag in package.xml may be used to still be able to upgrade  
> from horde to horde6.
>
>>> Of course that also means we need to release Groupware 5.3 and 6.0  
>>> in parallel, so people can have IMP 6.2 or 7.0 in their bundles.  
>>> Or is this going to become too complicated?
>>
>> Doing two different bundle releases, IMO, is too complicated and  
>> gives us one more release process to run - even if the PEAR  
>> installer would allow this (see above).
>>
>> I also think having a Groupware 6.0, based on Horde 5.3 would be  
>> extremely confusing - is it a BC breaking release or isn't it?  
>> Where are the major new features in such a version jump etc...
>
> Yeah, it may be just too complicated in the end.
>
>>> A side-effect would be that the  Groupware major versions are no  
>>> longer in sync with the Horde major versions. We could fix this by  
>>> releasing Horde 7 instead of Horde 6 once it's time for that.
>>
>>>>> Either way, it's still the current code in Git master that would  
>>>>> be released whether we call it IMP 7.0 or IMP 6.3. The  
>>>>> difference would be what happens with the rest of the code base  
>>>>> - if we can begin refactoring (and breaking BC) before this  
>>>>> release (which would make it Horde 6/IMP 7) or if we should wait  
>>>>> for the major refactoring (and make this release Horde 5.3/IMP  
>>>>> 6.3)
>>>>>
>>>>>> I am particularly interested in the kronolith upgrade (external
>>>>>> organizer etc) but if there are finite work packages in the library
>>>>>> stack (like conversion to namespaces which would be a large, but very
>>>>>> schematic task) I think I or a B1 colleague could step in.
>>>>
>>>> Alternatively we can try to identify the applications that people  
>>>> wait most for regarding new features, and only release those.  
>>>> I.e. we could release Kronolith 4.3 and still stick with IMP 6.2.
>
> 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.

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

> -- 
> Jan Schneider
> The Horde Project
> http://www.horde.org/
>
> -- 
> dev mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2007 bytes
Desc: S/MIME Signature
URL: <https://lists.horde.org/archives/dev/attachments/20160924/699a5439/attachment.bin>