Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
In order to get immediate test from QA team and timely feedbacks from the Community, I would suggest to shorten our development cycle for XOOPS 2.30.
Our previous plan was to implement all features available in XOOPS 2.2 into 2.30 before we get a public release.
However, considering developers' time availability, I think it would be better for us to release a minor version of XOOPS 2.3.* periodically in a certain time period, like two or three weeks, no matter how many new features are implemented in that minor version.
In this way, we can work with QA team and the Community more effective.
it is not me that have a task to write 2.3 codes but anyway i agree with phppp.
2.3 is not an ordinary release. the Core teams (old and new one) promised for years!!! that they unite 2 separate branches in one.but it is not happen yet and some people said it will never happen. so The sooner 2.3 release the less complaint from users.
i agree this strategy, if if the diagram of guideline of architecture is well defined
I agree with phpp, it's a good way "to change" completely the core of XOOPS with a soft migration.
As proposed by mboyden, if we can set up a validating propose like Ubuntu or Debian (it's the same thing), with different levels for modules and core. It will be really great and reassuring for users...
i agree this strategy, if :
- the overall picture is well defined (the final architecture)
- the branch merging process is well defined
- we start in parallel to document basic core elements (architecture, naming convention, DB arch.)
About features :
- are the 2.0x branch features already integrated in the first RC?
- about the 2.2x features, the most awaited deal with classes on the dev point of view. About the profile and PM module, there are already modules for that.
Lets focus on having a strong core, minimalist but effiscient, fully OO, that facilitates creativity.
Small steps make big steps : i much prefer frequent releases with well implemented features, than a 6 months + release that is quite impossible to test effisciently.
thanks for that proposal. it's time to help core dev.
Personally, I would prefer a minimal core overall with a slightly longer release cycle than what has been happening of recent (except for providing relevant security fixes which should be available immediately). I'd suggest a quarterly cycle of 3 months between releases (and can agree that 6 months might be too long). Why? Unless you manage only 1-2 sites, it's because of the number of sites to manage, perform regression and integration testing with, and other due diligence required to test each one of these releases. It takes time to do that before doing the migration to a new version, and then if you have a dozen of these to manage, it can be a vicious cycle trying to keep up (I'm still working to get them all to .18.x) while I'm trying to finish development of the profiles module while I'm also still trying to make a living building sites (mostly without xoops, but I keep trying to get them to use xoops) for clients.
However, if it was regular (think Ubuntu) and published, it might be a lot easier to manage and plan for from a total management standpoint. Security fixes and issues between releases really could be better dealt with somehow and then they get released into each new major core version.
I know a lot more goes into this, but I believe the Ubuntu community has it pretty well right from how to manage releases. Also, since we've had a couple of snafus with our upgrades in the somewhat recent future, you absolutely have to test and understand what has been changed, especially if you use anything that's even slightly non-standard core.
As a XOOPS user, I also agree this strategy.
To Mark Boyden (mboyden):
Sharpening the axe won't interfere with the cutting of firewood, but XOOPS is just a tool to help us in work, not our work itself. The more important thing is our work. As a XOOPS user, I would not follow all the update version unless security fixes. Nobody has enough time to follow all the softwares they used. This is my basic strategy to use any software.
However, I would like to see active development. I check XOOPS' SVN frequently, and it would give me more confidence and hope.