I think everyone agrees that having separate 2.0.x and 2.2.x branches is unacceptable. Fixing this should be a short-to-medium term goal.
I know that skalpa had planned on bridging these, but I don't know what progress, if any, had been made.
There are several possible approaches:
(I'll assume that 2.0.17 and 2.0.25 have been already been released, since those are short-term goals.)
A. Starting with the latest 2.3.x (2.3.0-A2?), merge in the new features from 2.2.25. Name the result 2.4.0.
B. Throw away the latest 2.3.x, start over with 2.0.17 and merge in the differences from 2.2.15. Name the result 2.4.0.
C. Throw away the latest 2.3.x, start over with 2.2.25 and merge in the differences from 2.0.17. Name the result 2.4.0.
D. Other?
In any case, a detailed comparison of 2.0.17 and 2.0.25 will be needed.
What's it going to be then, eh? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-06-15
I hope no one objects to my posting here?
My own suggestion would be: A
There are two variations of 2.3, from my understanding: The Alpha releases plus 2.3-dev - which I think was essentially 2.0 with fixes.
Including any new code from these releases, plus 2.0.17 as a basis would be a stable ground to adding the features added to 2.2.x branches (plus would ensure any other work wasn't wasted of course!)
As the essential difference between 2.2 and 2.0 was the profiling, block admin and pm module - why not for the short term use something based on Mith's work on SmartBlocks & SmartProfile - which was an updated version of his 2.2 work - to bridge the gap further?
As for PM module - French developer Venom is currently working on a re-write of his "MP Module"..
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think Dave_L's reasoning is more sound. There are many people using 2.2.x and 2.0.x while no one has (or should have) used 2.3 on a production site. While 2.3 does have interesting ideias, those could still be transported to a new merged code base.
For current 2.2.x users (such as myself) there are features of utmost importance such as:
- Integrated profiles. While smartprofile does allow you to create aditional profile fields, it does not allow individual modules to interact with it, such as 2.2.x. I've created modules that create their own custom fields.
- Block instancing. I haven't tried smart blocks yet so I can't comment if it's functionality is similar.
- Admin templating. This is very importante since I use custom templates for admin plus it's own blocks.
- PM i'm sure private messaging could be attained through one method or another.
Once again, I feel the emphasize should be a code merger between 2.0 and 2.2 disregarding the current 2.3 since it hasn't been implemented.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I have looked at what is in SVN, and XoopsCore/Trunk/ is the 2.3.0 branch, I'm not exactly sure what is in XoopsCore/branches/2.3.x/. Unless you want to roll back to 2.0.16 and start over, I think the way to proceed is to build on that code (option A).
BTW - XOOPSwiki.org was launched with 2.3.0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If we want to start with what's in the trunk, and no one knows exactly its state, it would probably be best to make a snapshot of it, name it something like 2.3.0-b1, and then start reviewing and testing it.
But then I'm not sure how trunk related to 2.0.16.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just compared releases/2.3.0-a2 and branches/2.3.x/2.3-main. The only difference is the file XOOPS/System/Frameworks/Logos/PageBuilder.xoobj/builder.php. releases/2.3.0-a2 contains a newer version (r440), branches/2.3.x/2.3-main contains an older version (r377).
The directories XOOPS and XOOPS-data are not in the trunk at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd certainly opt for 'A' and build upon the already started trunk of 2.3.
the 2.0.x core is outdated, and it would be far better to build upon skalpas efforts with the 2.3 branch which is new code & structure, rather than further modify the existing 2.0.x core to enhance it further.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As long as i can remember, skalpa had in 2.3:
- sliced all too heavy files of the 2.0x that needed to be divided into smallest ones. In a way he had prepared things so that it would be easy to improve core parts by parts, and that core would be quicker
- added a new template engine (2.0.14 has a derivated one, not so far from the 2.3 one)
- added fpdf support
- upgraded third party extensions (smarty, phpmailer, snoopy, etc.)
- changed things so that url rewritting would be easier
- started to rewritte some kernel classes
marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2.3a2 was the last release of the new re-architecture of XOOPS in the skalpa vision (formerly xoosphere)
2.3main is based on this alpha 2.
After that, due to difficulties he decided to restart from 2.0.13.2 to remove gradually the difference between 2.0.X and 2.2. Then we have had the 2.0.15 and finally then 2.0.16.
Actually the trunk is based on 2.0.16 and label 2.3.0-dev.
I think that we can keep this 2.3-dev version to be the new version of XOOPS with the fusion of 2.0.x and 2.2.x versions.
When it will be released this version will be labelled 2.4 (to follow the LINUX convention).
I don't know if we continue with the new architecture that skalpa has experiment in the 2.3 alpha. It's its own vision and if we keep it, we need to well understand it in the detail.
After that, i think that we need a new long term vision for XOOPS. (like skalpa vision but with actions).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-06-27
So - judging from what you say there Pemen - if any future work was started from 2.3.0-dev - towards joining 2.0 and 2.2 - then there would be no reason why some work could not be included from 2.3 alpha2 .... after people have had more chance to examine the code to make better use of it?
It would be a good starting block for future work - and it would save the work being wasted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Marcan and I chatted about this a short while ago and he asked that I post this synopis here for comment, clarification and/or ratification since this information is scatted across a few locations (some URLs below).
He was looking for the information on the decision about the merge of the 2.0.x and 2.2.x branches. We agreed essentially on the following points, much of which is discussed, but still looking to find the document that lays it out fairly clearly:
RELEASES 2.0.17 and 2.2.5 were bug fixes only. Next release is 2.4 merging 2.0.17, 2.2.5, and the best parts of 2.3. No enhancements, except as included in these branches and potentially a few others developed in other releases. This is the last PHP4 Release
* Enhancements Release is 2.6. This will be a PHP5 release.
CORE PRINCIPALS Separating core and modules is one true force of XOOPS and it needs to stay that way To solve the OOB (out of the box) issue, have the Modules team develop "modules packages" that can be easily deployed. Heck, we may even need a module package toolset of some sort to deploy multiple modules at once with particular configuration info.
* Core includes those things that EVERY installation MUST have (in our honorable opinions), for instance working with module developers of AltSys, XOOPScare, XOOPSinfo, etc., to incorporate those enhancements into the core (with their involvement, assistance, and permission, of course).
I am sure that the 2.6 release will not be published in 6 month... but the end of the support of php4 is not a real problem, PHP5 support most (or all, not sure) the PHP4 coded applications, the idea of coding in PHP5 is about that the core team will leave the support of the PHP4 code, and will start coding in another way, is more that date is a perfect date to start the UNsupport of php4 because (in theory) all hosting servers will be in PHP5.
I think that the first step, that the communty should do... is to merge the to branches, based in the last stable version of xoops2.0 branch (2.0.17), old the code done by skalpa should be fully studied, because had very interesting and usefull features to think in the future, but is a really new achitecture, and a full recode, wich i think it should be encared to the 3.0 release, a new full generation of XOOPS, but now is not the moment, or we are not ready for that, we have another issues first.
In short words for 2.4:
- Join the 2 branches 2.0.x and 2.2.x (The hardest part)
- Leave the PHP4 support, but not starting coding in PHP5 way. Join the GOPHP5 initiative. (if the community is able to support that change)
- Add some common librarys and features repeated in many modules and themes, as fpdf , prototype.js,
- Renew the theme :P (not fully important) --> Is allready done in the trunk
- Renew the admin (the usability and the look&fell --> EXM is a great way)
- Renew the Installer --> is allready done in the trunk
- Renew the module administration.
- Include some (the most special and usefull) Admin & Security features of XOOPSINFO , XOOPSCARE and PROTECTOR (and any other i forget) modules to the core.
- Include the more DB support(postgres is growing fast)
In short words for 2.6:
- Rewriting of some core classes to PHP5 code.
- Full Ajax Integration (Here we got many work)
- Multisite Development
In short words for 3.0:
Full recoding and rethink of the achitecture of the core. (Very probably based in 2.3 code of Skalpa)
That is my idea...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think everyone agrees that having separate 2.0.x and 2.2.x branches is unacceptable. Fixing this should be a short-to-medium term goal.
I know that skalpa had planned on bridging these, but I don't know what progress, if any, had been made.
There are several possible approaches:
(I'll assume that 2.0.17 and 2.0.25 have been already been released, since those are short-term goals.)
A. Starting with the latest 2.3.x (2.3.0-A2?), merge in the new features from 2.2.25. Name the result 2.4.0.
B. Throw away the latest 2.3.x, start over with 2.0.17 and merge in the differences from 2.2.15. Name the result 2.4.0.
C. Throw away the latest 2.3.x, start over with 2.2.25 and merge in the differences from 2.0.17. Name the result 2.4.0.
D. Other?
In any case, a detailed comparison of 2.0.17 and 2.0.25 will be needed.
What's it going to be then, eh? :)
I hope no one objects to my posting here?
My own suggestion would be: A
There are two variations of 2.3, from my understanding: The Alpha releases plus 2.3-dev - which I think was essentially 2.0 with fixes.
Including any new code from these releases, plus 2.0.17 as a basis would be a stable ground to adding the features added to 2.2.x branches (plus would ensure any other work wasn't wasted of course!)
As the essential difference between 2.2 and 2.0 was the profiling, block admin and pm module - why not for the short term use something based on Mith's work on SmartBlocks & SmartProfile - which was an updated version of his 2.2 work - to bridge the gap further?
As for PM module - French developer Venom is currently working on a re-write of his "MP Module"..
David
There are a couple of obvious typos in my post: "2.2.15" should be "2.2.25" and "2.0.25" should be "2.2.25".
"2.2.25"?
I guess my mind is gone. That should 2.2.5.
I agree with davidl2 (A option).
I think Dave_L's reasoning is more sound. There are many people using 2.2.x and 2.0.x while no one has (or should have) used 2.3 on a production site. While 2.3 does have interesting ideias, those could still be transported to a new merged code base.
For current 2.2.x users (such as myself) there are features of utmost importance such as:
- Integrated profiles. While smartprofile does allow you to create aditional profile fields, it does not allow individual modules to interact with it, such as 2.2.x. I've created modules that create their own custom fields.
- Block instancing. I haven't tried smart blocks yet so I can't comment if it's functionality is similar.
- Admin templating. This is very importante since I use custom templates for admin plus it's own blocks.
- PM i'm sure private messaging could be attained through one method or another.
Once again, I feel the emphasize should be a code merger between 2.0 and 2.2 disregarding the current 2.3 since it hasn't been implemented.
Well, I have looked at what is in SVN, and XoopsCore/Trunk/ is the 2.3.0 branch, I'm not exactly sure what is in XoopsCore/branches/2.3.x/. Unless you want to roll back to 2.0.16 and start over, I think the way to proceed is to build on that code (option A).
BTW - XOOPSwiki.org was launched with 2.3.0
I just checked out and compared https://xoops.svn.sourceforge.net/svnroot/xoops/XoopsCore/releases/2.3.0-a2 with https://xoops.svn.sourceforge.net/svnroot/xoops/XoopsCore/trunk. They are very different.
releases/2.3.0-a2 is at revision 378. trunk is at revision 807. branches/2.3.x/2.3-main is at revision 440.
Is it safe to assume that the latest changes are all in the trunk?
I used "svn log -r807:378 https://xoops.svn.sourceforge.net/svnroot/xoops/XoopsCore" to get a log of changes, but it's hard for me to tell from that.
If we want to start with what's in the trunk, and no one knows exactly its state, it would probably be best to make a snapshot of it, name it something like 2.3.0-b1, and then start reviewing and testing it.
But then I'm not sure how trunk related to 2.0.16.
I just compared releases/2.3.0-a2 and branches/2.3.x/2.3-main. The only difference is the file XOOPS/System/Frameworks/Logos/PageBuilder.xoobj/builder.php. releases/2.3.0-a2 contains a newer version (r440), branches/2.3.x/2.3-main contains an older version (r377).
The directories XOOPS and XOOPS-data are not in the trunk at all.
I'd certainly opt for 'A' and build upon the already started trunk of 2.3.
the 2.0.x core is outdated, and it would be far better to build upon skalpas efforts with the 2.3 branch which is new code & structure, rather than further modify the existing 2.0.x core to enhance it further.
As long as i can remember, skalpa had in 2.3:
- sliced all too heavy files of the 2.0x that needed to be divided into smallest ones. In a way he had prepared things so that it would be easy to improve core parts by parts, and that core would be quicker
- added a new template engine (2.0.14 has a derivated one, not so far from the 2.3 one)
- added fpdf support
- upgraded third party extensions (smarty, phpmailer, snoopy, etc.)
- changed things so that url rewritting would be easier
- started to rewritte some kernel classes
marco
A little bit of history :
After that, due to difficulties he decided to restart from 2.0.13.2 to remove gradually the difference between 2.0.X and 2.2. Then we have had the 2.0.15 and finally then 2.0.16.
Actually the trunk is based on 2.0.16 and label 2.3.0-dev.
I think that we can keep this 2.3-dev version to be the new version of XOOPS with the fusion of 2.0.x and 2.2.x versions.
When it will be released this version will be labelled 2.4 (to follow the LINUX convention).
I don't know if we continue with the new architecture that skalpa has experiment in the 2.3 alpha. It's its own vision and if we keep it, we need to well understand it in the detail.
After that, i think that we need a new long term vision for XOOPS. (like skalpa vision but with actions).
So - judging from what you say there Pemen - if any future work was started from 2.3.0-dev - towards joining 2.0 and 2.2 - then there would be no reason why some work could not be included from 2.3 alpha2 .... after people have had more chance to examine the code to make better use of it?
It would be a good starting block for future work - and it would save the work being wasted.
Marcan and I chatted about this a short while ago and he asked that I post this synopis here for comment, clarification and/or ratification since this information is scatted across a few locations (some URLs below).
He was looking for the information on the decision about the merge of the 2.0.x and 2.2.x branches. We agreed essentially on the following points, much of which is discussed, but still looking to find the document that lays it out fairly clearly:
RELEASES
2.0.17 and 2.2.5 were bug fixes only.
Next release is 2.4 merging 2.0.17, 2.2.5, and the best parts of 2.3. No enhancements, except as included in these branches and potentially a few others developed in other releases. This is the last PHP4 Release
* Enhancements Release is 2.6. This will be a PHP5 release.
CORE PRINCIPALS
Separating core and modules is one true force of XOOPS and it needs to stay that way
To solve the OOB (out of the box) issue, have the Modules team develop "modules packages" that can be easily deployed. Heck, we may even need a module package toolset of some sort to deploy multiple modules at once with particular configuration info.
* Core includes those things that EVERY installation MUST have (in our honorable opinions), for instance working with module developers of AltSys, XOOPScare, XOOPSinfo, etc., to incorporate those enhancements into the core (with their involvement, assistance, and permission, of course).
BIBLIOGRAPHY
Relevant URLs:
* http://sourceforge.net/forum/message.php?msg_id=4413265 (goodbye to PHP4)
ª http://xoops.wiki.sourceforge.net/MeetingNotes20070703 (notes from first online team meeting)
ª http://sourceforge.net/forum/message.php?msg_id=4364565 (team discussion)
ª I'm also looking for the notes from our overall meeting that we did via a bit online chat.
So, did I get any of our decisions wrong? Let's discuss. Thanks for all the work on the latest releases.
i fully agree with this release plan. but have you a timeline in mind?
don't forget that php4 will be death in 6 months... will be the 2.6 out for this date?
I am sure that the 2.6 release will not be published in 6 month... but the end of the support of php4 is not a real problem, PHP5 support most (or all, not sure) the PHP4 coded applications, the idea of coding in PHP5 is about that the core team will leave the support of the PHP4 code, and will start coding in another way, is more that date is a perfect date to start the UNsupport of php4 because (in theory) all hosting servers will be in PHP5.
I think that the first step, that the communty should do... is to merge the to branches, based in the last stable version of xoops2.0 branch (2.0.17), old the code done by skalpa should be fully studied, because had very interesting and usefull features to think in the future, but is a really new achitecture, and a full recode, wich i think it should be encared to the 3.0 release, a new full generation of XOOPS, but now is not the moment, or we are not ready for that, we have another issues first.
In short words for 2.4:
- Join the 2 branches 2.0.x and 2.2.x (The hardest part)
- Leave the PHP4 support, but not starting coding in PHP5 way. Join the GOPHP5 initiative. (if the community is able to support that change)
- Add some common librarys and features repeated in many modules and themes, as fpdf , prototype.js,
- Renew the theme :P (not fully important) --> Is allready done in the trunk
- Renew the admin (the usability and the look&fell --> EXM is a great way)
- Renew the Installer --> is allready done in the trunk
- Renew the module administration.
- Include some (the most special and usefull) Admin & Security features of XOOPSINFO , XOOPSCARE and PROTECTOR (and any other i forget) modules to the core.
- Include the more DB support(postgres is growing fast)
In short words for 2.6:
- Rewriting of some core classes to PHP5 code.
- Full Ajax Integration (Here we got many work)
- Multisite Development
In short words for 3.0:
That is my idea...