Re: Horde 6 vs. Horde 5.3
Michael J Rubinsky <[email protected]> Wed, 14 Sep 2016 16:34:50 +0000
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <20160914163450.Horde.BGQjsTYvQZsZtLl1-4k-KG4@h4.theupstairsroom.com> |
Quoting Jan Schneider <[email protected]>: > Zitat von Jan Schneider <[email protected]>: > >> Zitat von Michael J Rubinsky <[email protected]>: >> >>> Quoting Ralf Lang <[email protected]>: >>> >>>> 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: [email protected] -- mike The Horde Project http://www.horde.org https://www.facebook.com/hordeproject https://www.twitter.com/hordeproject -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]
smime.p7s
(application/pkcs7-signature, 2 KB) - not displayed