Not sure where I remember reading this but the more I think about it the more it makes sense...

With all of the wholesale changes to xoops to make the 2.6 branch someone else suggested maybe it would warrant changing the branch name to 3.0 instead of 2.6.

This is the biggest change to xoops since the 2.0 branch was made and I think I can agree with the person who suggested it. When you look at normal versioning of programs a whole number is normally used when you make huge changes to the structure. A decimal version is for reasonably minor additions. I think the core programmers have done a great job of upgrading xoops from what I can tell and from the bits and pieces trabis has mentioned I don't think it is doing Xoops justice to call this the 2.6 branch anymore. I want to believe that we have made the biggest wholesale changes to Xoops in probably a decade and it should warrant moving to call it 3.0. I also believe this version has gone much further than any of us had anticipated when it was started. SO I personally think we should consider, and maybe put to a vote, changing this upcoming version to 3.0 and we can then call the currently planned alpha 3 version of 2.6 the alpha 1 version of 3.0 and retire the 2.x branch entirely. (Other than simple security fixes to 2.5.x branch)

Because there is so much of the original code that has been refactored and so much has been changed and the way things are done are being done differently I really think it is a great idea to reconsider the versioning of this branch. If we want to make sure it is not confused with the failed prior attempts at a 3.0 branch we could even jump and call it 4.0 to prevent confusion. I also think because we will need improvements to the modules to work with the 2.6 branch and the moving away from MySQL as the connector it will also help the users know that they need upgraded modules to work with this branch. I think it will go a long ways to prevent users confusion if the modules all need even basic adjustments to work properly with 2.6.

One big reason for this tract for me is because we have a few modules that ran under 2.0.18 that still run under 2.5.5 and some other just need very simple modifications to run under 2.5.5. With 2.6 I don't believe any of those modules will work 100% without some tweaking. Any of the OLD modules written to proper coding techniques using the xoops API as documented and using php4 procedural features and no OOP still stand a chance to run under 2.5.5. They stand a significantly lesser chance of running under 2.6 without some adjustments throughout the code. Calling them 2.6 compatible modules is not really accurate because with normal versioning that would mean the program likely works with 2.5 and 2.4 without issues and unless I am mistaken I don't believe that is the case with 2.6 without some if/then or case statements to support before and after 2.6 versions. And I am sure the programmers will do their best to try not to break stuff that work under older versions but Personally I think because of the additional power we are adding we should depreciate compatibility with the <2.6 API and consider that at a 3.1(4.1) branch we remove the 2.x branch compatibility. I think this is a huge move forward. We would also need significant documentation to explain how to make a <2.6 compatible module 3.0(4.0) compatible and try to make it easy for non php programmers to understand.

By doing things this way I don't think we totally alienate the old modules but they will all need to be updated to run with the newer system regardless so I strongly think we should consider changing the branch to a 3.0(4.0) version.

(These posts never seem so wordy when I write them... LOL... )

Quote:
I guess, I will never understand the obsession with version numbers

Linux was introduced 21 years ago, and it is now at 3.7.1 version. And they seem to be doing just fine!

To compare, Firefox was recently 4.0, and now they are already at version 17.01

And let's look at Chrome browser too: it's already at 23.0.1271.97

Does it mean that Chrome and Firefox teams are doing better job than Linux Team? I don't think so!

In XOOPS history, Skalpa wanted to jump right away from 2.0.x to 4.0, because of his new proposed architecture. Unfortunately, nothing materialized

We have announced that the next version is 2.6.0, so let's not try to change it in the middle of everything. We have news, we have published press releases, we have published stories about it, and now the updated roadmap.

Let's not confuse everybody! And I don't believe that we'll get suddenly new users because our version will be 25.0

They will come and use XOOPS if we provide them with the features and functions and benefits they are looking for!

Why don't we focus on delivering a solid XOOPS 2.6.0 version, that will make things easier for both users and developers, and not worry too much about the version numbers?

Quote:
true.
I think i was the person that mentioned version 3.0 but i just want to emphasis tones of changes had been done in 2.6 can not be considered to what has been done in for example moving from 2.4 to 2.5 and Mamba I compared Xoops versions to Xoops not any other projects.

The changes are huge and what community expect for almost 10 years.

But im agree with mamba lets do not play with version numbering as before. (yeah i recall what Skalpa did!)
what is important is the current core team did the great job and great team working and continue in the right direction. Community just should be informed about those huge changes to be prepared for the big step (upgrade from 2.5 to 2.6) and i think our posts are enough for this purpose.

Quote:
I did talk to Trabis few weeks ago about the process of module conversion to XOOPS 2.6.0, and we both agreed that it is a very important issue, and we should be focusing on making it as easy as possible. The focus right now is to make XOOPS 2.6.0 as good as possible, but then we should look into ways to make the conversion as easy as possible. It could mean adding some tools to help with automating the process, it could mean to add some workarounds or small "legacy or conversion layer" with deprecated notices, that won't impact the Core itself, or some other ways.

The current reality is that there are only few people working on converting modules to XOOPS 2.5.5 GUI, and even less doing a full "Blue Move API" conversion (YES, we are looking for volunteers to help!!!! ). So how many people will we get to do the full "XOOPS 2.6.0 API Conversion"? I hope, we'll get a lot of, because all of them will be excited about XOOPS 2.6.0, but in case there are not that many, we have to make sure that the process is easy.

The important thing is: we are only in pre-Alpha 2 phase, and till RC a lot of things can change

One more comment about version numbers: the classical scheme of assigning version numbers is pretty much gone. If you look at Ubuntu, they just do release twice a year, in April and in October, and call it by the year and month, so you have 12.04 and 12.10, and the next coming will be 13.04.
And the version 17 of Firefox, was not so dramatically different from version 16. And the 18 won't be so different from 17. It really doesn't matter anymore.

Just a Request for update module process, I think it good if all changes and update down on update module system. just the important thing is big tables.

for example we want change a module table Structure and move data from old table to new table. module update process must do it step by step. and in each step process 300 rows and in next step process next 500 rows

* 300 is an example number, between 100 to 300 row in each query Cycle is enough. more than this number ( for example 1000 ) makes crash in mysql

Quote:
This issue came up with discussion with Trabis (e.g. importing big tables from one module to another into Publisher). He is thinking about using callbacks, but this is still work in progress/research. Important thing - he is very much aware of it.