We may need Midgard 1.9 after all
-
Henri Bergius
We may need Midgard 1.9 after all
Mon July 23 2007 11:31:23 UTCHi!
The current Midgard roadmap says that Midgard 1.8 (and MidCOM 2.8)
will be the last major series of the "old" Midgard.
However, after some thought and discussion with users (and potential
users), I've started believing that we may after all need to make
Midgard 1.9 before taking the "ragnarok" and jumping to 2.0.
The reasons are the following:
* We need to practice making a solid and easy-to-install release so we
can avoid lots of problems with 2.0 stable
* PHP4 has received an End-of-Life notice, and we should have one
classic release that supports only PHP5 (the code will work also with
PHP4 as you know, but we don't have to support it)
* We need a baseline version from which users can later migrate to
2.0, and I believe 1.8 series is too varied for that (too many changes
between minor releases)
* It will still take a while before Midgard 2.0 and MidCOM 3.0 are
stable, so we need a release people can live with
The main thing here is to coordinate the release so that we have a
fully working, stable MidCOM 2.8 in PEAR and binary packages of
Midgard to the main platforms.
To make this happen, I'd propose the following tasks to various contributors:
* Juhana: test plan for installation and site setup, site wizard finishing
* Tarjei: make phing bundle phpdocs of components into packages
* Andreas Nilsson: icons for main Midgard features (I'll mail a list separately)
* Rambo: statistics collector and mailer that will send statistics of
weekly/monthly/yearly downloads and site registrations to this list
* Arttu: fixing style editor and moving it to Asgard
* Solt: DM2 schema editor
* Osku: changes needed on m-p.org for the new Help menu (searching
discussion by component etc)
* Anykey guys: finish the Help menu
* Bergie: floating toolbar ACLization
* Jerry: Mind mapper to site structure system
* Piotras: fix datagard, sensible defaults etc
In addition to these, testing and localization help is wished from
everybody in the community. This release *must* work solidly. People
are also welcome to contribute site structure and layout templates.
Especially fixing datagard is crucial. With current packages
installing Midgard itself is easy, but problems come with datagard
bugs. In optimal situation Midgard packages would just create database
and host in post-install phase without questions asked.
What do you think? I'd try to target early September for this release.
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: We may need Midgard 1.9 after all
Mon July 23 2007 12:08:14 UTCHi!
Hi!
However, after some thought and discussion with users (and potential users), I've started believing that we may after all need to make Midgard 1.9 before taking the "ragnarok" and jumping to 2.0.
I am very confused in this matter, but more + than -.
- We need to practice making a solid and easy-to-install release so we can avoid lots of problems with 2.0 stable
Which means we need to write installer from scratch.
- PHP4 has received an End-of-Life notice, and we should have one classic release that supports only PHP5 (the code will work also with PHP4 as you know, but we don't have to support it)
Which means we need to create 1-9 branch from 1-8. For me creating another branch which will be part of 1-8 and part of trunk means real hell, but if we need to do this let's drop PHP4 support.
1-8 is addressed for PHP4 and PHP5. Writing code on any level to keep PHP4 compatibility means wasting time IMHO.
- We need a baseline version from which users can later migrate to 2.0, and I believe 1.8 series is too varied for that (too many changes between minor releases)
This is what I am not sure. Baseline version from 1-8 branch is always latest release. The same will be with 1-9.
- Piotras: fix datagard, sensible defaults etc
There's nothing which can be done in bash to make DG better. Of course I mean sensible amount of time needed to write it with bash scripting.
Last but not least. Do you want 1-9 be semi production , production or development one?
Piotras
-
Re: We may need Midgard 1.9 after all
Mon July 23 2007 12:20:17 UTCHi,
Which means we need to create 1-9 branch from 1-8. For me creating another branch which will be part of 1-8 and part of trunk means real hell, but if we need to do this let's drop PHP4 support.
I wouldn't do any actual code modifications to purposefully not support PHP4. Instead, PHP4 may work if it does, but we don't package for it or help users with it.
This is what I am not sure. Baseline version from 1-8 branch is always latest release. The same will be with 1-9.
This is mostly related to that we need to say clearly: "if you run this version we will make it easy/possible to migrate to Midgard2".
Also, I believe dropping PHP4 support helps here. Lots of MidCOM related things we can do programmatically when migrating, but if user has code in styles or snippets that doesn't run on PHP5 it will be very difficult for us to support them.
So if the PHP4-to-PHP5 jump happens before Midgard2 support work is easier.
There's nothing which can be done in bash to make DG better. Of course I mean sensible amount of time needed to write it with bash scripting.
Probably we need to do new installer from scratch. But then again, we need to do this anyway before 2.0.
PHP-CLI is probably the best environment to do this in.
BTW, as to Apache configs, I'd consider reviving the
apacheupdate.plapproach that Nadmin Studio had and generate vhost configs based on data in host table. This should help keeping the two in sync.Last but not least. Do you want 1-9 be semi production , production or development one?
Stable, solid and tested production. We need to practice making this, and synchronizing the releases of Midgard and MidCOM to make it happen.
/Bergie
-
-
Re: We may need Midgard 1.9 after all
Mon July 23 2007 13:10:04 UTCHi!
I wouldn't do any actual code modifications to purposefully not support PHP4. Instead, PHP4 may work if it does, but we don't package for it or help users with it.
So we need to create branch-1-9 with only midgard-data. The rest should be done in 1-8 branch. From Midgard ( core + apache module + php ) point of view it means we change only ( and only ) setup part.
So if the PHP4-to-PHP5 jump happens before Midgard2 support work is easier.
Yeah , but still, we need to partially rewrite MidCOM once again before 2.0 is out.
Piotras
-
-
Re: [midgard-dev] Re: We may need Midgard 1.9 after all
Mon July 23 2007 13:16:51 UTCOn 7/23/07, Piotr Pokora <piotr.pokora@infoglob.pl> wrote:
> Yeah , but still, we need to partially rewrite MidCOM once again before 2.0 is out.
Of course, but the question is whether the stuff done by users (like
site templates) will be PHP5 compatible and so possible to migrate to
whatever format MidCOM 3 uses.
> Piotras
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: We may need Midgard 1.9 after all
Tue July 24 2007 08:25:42 UTCHi!
I have been thinking about two scenarios:
"Extend" 1.8 branch
Keep midgard-core, midgard-apache and midgard-php as is. Write new installer ( PHP5 only ), add it as optional experimental installer and replace DG once it's stable.
Pros
- No need to create yet another branch
- Issues may appear mostly during setup, the rest is kept stable
Cons
- DG is designed to make update from previous releases ( even 1.4 ) so we need to keep it anyway.
- We can not release it as 1.9, only as 1.8.x
Create new 1.9 branch
Keep midgard-core and midgard-apache. "Backport" midgard-php from trunk.
Pros
- We can focus on pure PHP5 MidCOM
- Improved performance on php level
- Upgrade to 2.0 will be easier because midgard-php extension and MidCOM is already rewritten.
Cons
- Time needed to backport midgard-php for legacy core and midgard-apache might be too long
- It's error prone to keep three different branches.
- Database format is not going to be changed a lot so 1.8.x release is still required as Midgard2 "jump point" for older midgard versions.
Piotras
-
Re: [midgard-dev] We may need Midgard 1.9 after all
Tue July 24 2007 13:39:59 UTCHi there,
> The current Midgard roadmap says that Midgard 1.8 (and MidCOM 2.8)
> will be the last major series of the "old" Midgard.
>
> However, after some thought and discussion with users (and potential
> users), I've started believing that we may after all need to make
> Midgard 1.9 before taking the "ragnarok" and jumping to 2.0.
The main problem here is the term "ragnarok". It is never a good idea to
try a complete rewrite of everything. It usually just ends up killing
the project.
>
> The reasons are the following:
>
> * We need to practice making a solid and easy-to-install release so we
> can avoid lots of problems with 2.0 stable
IMHO: Most of the problems we have seen lately come from two sources:
a) DG is hard to debug / adapt
b) DG + pear makes for trouble.
> * PHP4 has received an End-of-Life notice, and we should have one
> classic release that supports only PHP5 (the code will work also with
> PHP4 as you know, but we don't have to support it)
For MidCOMs part, 2.8 partly supports PHP4 (not the indexer) and the
next release will not. Is there any spesific functionality that is
needed in 1.9 that is not in 1.8.4?
IMHO we should call this release 1.8.5 and then start releasing 1.9
releases with each release providing a new feature.
> * We need a baseline version from which users can later migrate to
> 2.0, and I believe 1.8 series is too varied for that (too many changes
> between minor releases)
In other words, we need a release series where we can backport new
features from 2.0 until the 1.9 series are everything we would like to
call 2.0 and then rename it. IMHO that would be the best way forward.
> * It will still take a while before Midgard 2.0 and MidCOM 3.0 are
> stable, so we need a release people can live with
Yep. What would be nice is if the eventinterface discussed earlier would
be in 1.9.0. This would make it possible to get rid of DBA quite early.
> The main thing here is to coordinate the release so that we have a
> fully working, stable MidCOM 2.8 in PEAR and binary packages of
> Midgard to the main platforms.
> To make this happen, I'd propose the following tasks to various
> contributors:
>
> * Juhana: test plan for installation and site setup, site wizard
> finishing
> * Tarjei: make phing bundle phpdocs of components into packages
Is this a good idea?
> * Andreas Nilsson: icons for main Midgard features (I'll mail a list
> separately)
> * Rambo: statistics collector and mailer that will send statistics of
> weekly/monthly/yearly downloads and site registrations to this list
> * Arttu: fixing style editor and moving it to Asgard
> * Solt: DM2 schema editor
> * Osku: changes needed on m-p.org for the new Help menu (searching
> discussion by component etc)
> * Anykey guys: finish the Help menu
> * Bergie: floating toolbar ACLization
> * Jerry: Mind mapper to site structure system
> * Piotras: fix datagard, sensible defaults etc
Andreas Flack posted some bugs that we need to fix as well.
>
> Especially fixing datagard is crucial. With current packages
> installing Midgard itself is easy, but problems come with datagard
> bugs. In optimal situation Midgard packages would just create database
> and host in post-install phase without questions asked.
Hmm, who will rewrite it? IMHO DG should be rewritten as a set of phing
tasks or cli scripts that also handle upgrading from 1.4.
> What do you think? I'd try to target early September for this release.
Sounds doable. I hope we can get MidCOM 2.8 out a bit earlier so we can
get a polished release.
Regards,
Tarjei
>
> /Bergie
>
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] We may need Midgard 1.9 after all
Tue July 24 2007 13:56:48 UTCOn 7/24/07, tarjei <tarjei@nu.no> wrote:
> The main problem here is the term "ragnarok". It is never a good idea to
> try a complete rewrite of everything. It usually just ends up killing
> the project.
This is not a complete rewrite. Midgard 2 API has mostly been around
for a while already, and MidCOM 2.8 runs completely in it (except for
the few missing bits like user handling and style engine).
However, as you know we need to make *big* changes in MidCOM series,
and this is the natural time to do them.
> IMHO: Most of the problems we have seen lately come from two sources:
> a) DG is hard to debug / adapt
> b) DG + pear makes for trouble.
Which is why DG has to go.
> For MidCOMs part, 2.8 partly supports PHP4 (not the indexer) and the
> next release will not. Is there any spesific functionality that is
> needed in 1.9 that is not in 1.8.4?
1.9 is just Midgard 1.8.4 + MidCOm 2.8.0 + rewritten data install.
But the point is, we should officially say we are not supporting PHP4
in 1.9. If people migrate to PHP5 for Midgard 1.9, then we have a lot
less hassle when people in future start making 1.9-to-2.0 migrations.
> In other words, we need a release series where we can backport new
> features from 2.0 until the 1.9 series are everything we would like to
> call 2.0 and then rename it.
You got me wrong. The idea of 1.9 is to be a solid release from which
upgrading to 2.0 will be possible.
When we have the new page-based MidCOM 3 it will be much easier to
make migration scripts for it once we only need to target specific
version of Midgard and MidCOM as the source to migrate from.
> Yep. What would be nice is if the eventinterface discussed earlier would
> be in 1.9.0. This would make it possible to get rid of DBA quite early.
We can't get rid of DBA for Midgard 1.9. But we can get rid of it for
MidCOM 3.0 and Midgard 2.0
In other words, we can kill DBA in trunk right now if we want.
> > * Tarjei: make phing bundle phpdocs of components into packages
> Is this a good idea?
I think it is.
Now a big problem is that the API docs don't get generated and
updated, and I think it would be nice to provide them in the package.
> Andreas Flack posted some bugs that we need to fix as well.
Are they in trac?
> Hmm, who will rewrite it? IMHO DG should be rewritten as a set of phing
> tasks or cli scripts that also handle upgrading from 1.4.
Piotras and Rambo will be assigned to this. But of course, others are
welcome to debate and join in :-)
> Sounds doable. I hope we can get MidCOM 2.8 out a bit earlier so we can
> get a polished release.
Yeah. We still have a way to go for that:
http://trac.midgard-project.org/query?status=new&status=assigned&status=reopened&milestone=MidCOM+2.8
> Tarjei
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] We may need Midgard 1.9 after all
Tue July 24 2007 14:03:37 UTC>
> > Andreas Flack posted some bugs that we need to fix as well.
>
> Are they in trac?
>
I posted these two:
http://trac.midgard-project.org/ticket/61
http://trac.midgard-project.org/ticket/62
But I don't know if this is what he was referring to. I posted some stuff to
the list as well and I can turn it into bug reports if that helps
Bye,
Andreas
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] We may need Midgard 1.9 after all
Tue July 24 2007 14:15:45 UTCOn 7/24/07, Andreas Flack <flack@contentcontrol-berlin.de> wrote:
> I posted these two:
>
> http://trac.midgard-project.org/ticket/61
> http://trac.midgard-project.org/ticket/62
Good, I moved both to the correct milestone (MidCOM 2.8) so we don't
lose track of them :-)
> But I don't know if this is what he was referring to. I posted some stuff to
> the list as well and I can turn it into bug reports if that helps
Having tickets of each bug report helps. Mails get easily lost.
> Andreas
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
