I've seen a whitepaper post by Wishcraft, and I've looked at a few of the 2.6 modules and it seems to be there's been a bunch of changes to some basic functions.

What is a good resource to keep track of all the changes going on in 2.6 versus earlier revisions of the code? I'm going to start putting together a doc on my findings and want to know a good place to get information.

I developed and used the module more to get realtime listener demographics, since it also stores user agents and those kinds of things. I suppose I could have used a log parser, but that's not as much fun as what I was hoping I could get out of XOOPS. :)

I've been working on some other updates, but here is the latest for my IceAuth module:

Release v0.93 ::2013-06-29

Feature Adds
Now caputres and stores referers sent on a listener_add. (IceCast 2.3.3 KH)
User Agent bans are now allowed. This is a needle in a haystack search, where the needles are stored on the site, and the haystack is the UA reported by IceCast.

Code Changes
Converted to XOOPS 2.5.5 Admin GUI.

Fixes
Fixed a SQL query which prevented disconnect accounting from matching up a connection log entry in newer release of MySQL.

Notes
Development environment upgraded to XOOPS 2.5.6.
Code is now stored on GitHub!

Release v0.92 :: Not Released

Fixes
Module: Modified an accounting query which would fail when clocks change where daylight/standard time is used.

Notes
A bugfix release that was never actually released.

Available here, as always:http://xoops.underwood-hq.org/modules/wfdownloads/singlefile.php?cid=1&lid=3

I'll look at the link. There was no such helpful information when I first started writing these things.

Though my peeve so far is that for whatever reason, one of my modules won't let me go to its admin area. "You don't have permission to access this area." I'll need to see what's missing, because it's making me batty.

I really like what I see coming up in 2.6.0, and I am very much aware that it's still in an early alpha stage of testing.

I will, however, state my surprise that some of what I just converted to the 2.5.5 Admin GUI won't actually work in 2.6.0. Admittedly, this disappointed me, and looking at the changes, my first thought was "Damnit ... I just changed the GUI!"

I also do not mind learning another set of changes, either. However, until there's a shim layer in place so I don't have to go in and change all my $xoopsDB object calls, I can't say I'm in favor of calling this a v2 release.

And you are spot on as far as versioning being somewhat meaningless. XOOPS 2 has had many forks, many of which work fine with other XOOPS 2 modules. But with the changes to the backend, it might be time to move it up.

I think I've thrown enough cents at this opinion today. I eagerly anticipate future releases as 2.6 goes through further refinement.

I won't participate in the Simon beating at this time, but I did get a chance to look through the white paper highlighting the changes.

From my perspective as a module developer and a user, it appears to me that modules written before 2.6 will not work with 2.6. I accept this as the way it goes, particularly with the work done on the back end.

However, XOOPS has been perfectly content in the 2.x series to largely work with modules written for previous minor releases. I've still got some modules I've written for XOOPS 2.3 that work fine under 2.5. There have been tweaks and such along the way, but minor revision upgrades have been by and large inconsequential, especially from XOOPS 2.3 up through the recent 2.5.6.

That said, I think all the back end work in 2.6 justifies a major version bump. The changes in 2.6 alpha from 2.5 justify moving to a new major revision. Here's why:

* Module changes to support 2.6 are incompatible with prior releases entirely. This isn't an issue of writing a couple of checks in code to support some of the quirks either.
* Site dependencies on modules incompatible with 2.6 will slow its adoption.
* Users who expect another minor revision upgrade are in for a nasty surprise, no matter how good the documentation is written.

That said, and after the debacle with XOOPS 3, I think the upcoming release is a big enough deal to call XOOPS 4.

I had not considered a feature lock in place for 2.5.x, though it is a largely sensible practice.

Looking at the differences in help.php between 2.5.6 and 2.6.0-alpha2, the implementation of the enhancement as I've described looks like it should carry over from one version to the other without too much difficulty.

However, I figured I could offer a solution to the problem instead of just whining about it. :)

There were a few assumptions and errors I wanted to clear up. Here's the diff between my patched file, and the one with the XOOPS 2.5.6 distribution:



And here's the full file if anyone is interested:

Crew,

Since i've been moving a couple of my modules to the new Admin GUI, I cannot help but notice how lacking the help interface is for things other than the System module. This is something that we really should change since there are a number of modules that can be quite verbose as far as what quality help content could be.

To that end, I propose extending the help system from a module developer's perspective by making a new array available called "Help Section" implemented something like this:



The trick is in the implementation, as help.pho handles four help classifications:
* mid > 0, system
* mid > 0, non-system
* general, system
* genera, non-system

The first segment I've changed is mid > 0, non-system:



The second change is general help, non-system.



The code could probably use a little optimization, but it does make it possible for modules to have more than one single page.

Additionally, if the system module could be updated to support this in the main section instead of each little subsection, the code for this piece of the admin puzzle could be significantly shorter.

Looks like I updated all the metadata, but forgot to change the file itself. That has been fixed.

Updating releases on SourceForge is something I could be interested in. However, I have no love for subversion after I got my mits on Git and SourceTree. :)