[dev] Horde 6 vs. Horde 5.3

Wed Sep 14 16:34:50 UTC 2016

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

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

> 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.
>
>
>
> -- 
> 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/20160914/92cc8f80/attachment.bin>