Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[dev] Horde 6 vs. Horde 5.3
27 views
Skip to first unread message
Jan Schneider
Jun 15, 2016, 6:15:29 AM6/15/16
to
Hi,
since we have been asked recently when to expect Horde 6, and what
could be done to speed up its release, I'd like to discuss an
alternative option to release Horde 5.3 first.
Many new features have gone into master since the Horde 5.2 release,
few of them sponsored by clients or contributed by the community. The
expectation to see those features in a stable release within a
foreseeable timeframe is more than justified.
We could speed up the Horde 6 release by additional sponsoring, but
it's not only a matter of money, but also a matter of developer
resources. With Michael and me being the only remaining active core
developers at the moment, we rather lack developer time. Especially
for core development like infrastructure stuff, namespace refactoring
etc. that are not easy for contributors to jump in.
AFAIK we don't have any BC breaks in master yet, at least none that
couldn't be solved with bumped dependencies. So doing a 5.3 release
should work. Michael, please correct me if I'm missing something.
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.
Jan.
--
Jan Schneider
The Horde Project
http://www.horde.org/
--
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: dev-uns...@lists.horde.org
since we have been asked recently when to expect Horde 6, and what
could be done to speed up its release, I'd like to discuss an
alternative option to release Horde 5.3 first.
Many new features have gone into master since the Horde 5.2 release,
few of them sponsored by clients or contributed by the community. The
expectation to see those features in a stable release within a
foreseeable timeframe is more than justified.
We could speed up the Horde 6 release by additional sponsoring, but
it's not only a matter of money, but also a matter of developer
resources. With Michael and me being the only remaining active core
developers at the moment, we rather lack developer time. Especially
for core development like infrastructure stuff, namespace refactoring
etc. that are not easy for contributors to jump in.
AFAIK we don't have any BC breaks in master yet, at least none that
couldn't be solved with bumped dependencies. So doing a 5.3 release
should work. Michael, please correct me if I'm missing something.
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.
Jan.
--
Jan Schneider
The Horde Project
http://www.horde.org/
--
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: dev-uns...@lists.horde.org
Thomas Jarosch
Jun 15, 2016, 1:30:49 PM6/15/16
to
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
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.
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
Ralf Lang
Jun 15, 2016, 1:54:45 PM6/15/16
to
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
>
- 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.
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.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: la...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Jan Schneider
Jun 16, 2016, 10:08:40 AM6/16/16
to
Zitat von Michael J Rubinsky <mrub...@horde.org>:
> 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.
>
> 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
>> 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.
most for regarding new features, and only release those. I.e. we could
release Kronolith 4.3 and still stick with IMP 6.2.
0 new messages