Versioning of Plugins

[cmb]

Hello Developers,

discussing about translations of CMSimple_XH and the plugins, the idea came up, that it would be good to have a somewhat common versioning theme and a common way to access these version numbers. As far as I can see most plugins already use version numbers that are compatible to version_compare(), what's IMO very reasonable. What's currently missing is a common way to read this version number. The latter is an obstacle for several good uses of those version numbers:

• Under CMS->Info all installed plugins are listed -- but the version number is missing
• an automated update availabilty check needs those version numbers
• Translator_XH could insert those version numbers to the translated language files
• a plugin that relies on another plugin might have to know its version number, to cater for a changed interface (e.g. if Register_mod_XH changes its session variable names, Chat_XH will break without the chance to check Register's version)

So IMO it would be nice, if we could agree on a common way how this version numbers can be accessed from the core and other plugins. Please note, that making them available via index.php as constant, function or variable might be a simple and elegant way, but this couldn't be used reliably by other plugins, as the plugins are included in an indetermined order, and there's currently no way, to register a function, that will be called after all other plugins were loaded (what's IMO missing anyway<ADD>; I'd rather avoid misusing register_shutdown_function() for this purpose</ADD>). In preparation for an update availability check, Holger started to deliver his plugins with an *.nfo file containing the version number among other information. A viable solution too.

But independent of how the version info is available, it's only of great use, if as many plugin as possible provide it this way.

And, as I've already written in http://www.cmsimpleforum.com/viewtopic.php?f=2&t=4492&start=10#p27038:

Another thing oldnema made me aware of: it would be very helpful for translators, if the developers will state somewhat about the stability of their original language files. E.g. to state, that no new languages will be introduced in the 1.5.x series as it's the case for CMSimple_XH.

What do you think? Can we find an agreement?

Christoph

[svasti]

Very good idea. I could imagine that adding a .nfo file is practical, as this could easily be added to existing plugins.
Now, what would be the specification of the .nfo file?

[Hugorm]

You deside - but users.....?
Might you considder a method or process either to separate or to sort plugins after their usuablity compared to CMSimple version.

At the moment there are many installations and plugins working around the world (many available on the wiki too) which are not _XH.
Many new plugins are only _XH.

Can the indicated 'numbering' make a testing method and a sorting posible?

Hugo

[Tata]

Now, what would be the specification of the .nfo file?

IMHO:

Code: Select all

/* utf8-marker = äöüľščťžýáíéňô */
/*
  ======================================
CMSimple or Plugin name: xxxxxxxxxxx_version (language)
Release date: dd.mm.yyyy
Default language: xx
Translator: Name (Nick) - email(at)domain.tld - url
Based on Plugin name: xxxxxxxxxxx_version released dd.mm.yyyy
For changelog, downloads and information please see http://www.domain.tld
  ======================================
  -- COPYRIGHT INFORMATION START --

 
  -- LICENCE TYPES SECTION START --

  CMSimple or Plugin name: xxxxxxxxxxx_version is available under ....... license:

  -- LICENCE TYPES SECTION END -
  ======================================
 */


This should be placed into each index.php file of the CMSimple_XH core and/or of each plugin.
The same the without copyright and licence information into each other PHP file incl. languages.
But maybe I am wrong. Anyway - it happened a couple of time, that I have mixed files from vareoius versions of either the core or some plugins and then wondered that things didn't work.

Here new idea arose, how about to put small check function in relevant index.php, which would check if all important files belong to the same version?

[cmb]

Hi Frank, hi Hugo, hi Tata,

Now, what would be the specification of the .nfo file?

I guess Holger (or his plugins containing such .nfo files) can tell more about that.

Might you considder a method or process either to separate or to sort plugins after their usuablity compared to CMSimple version.

You're referring to marking plugins as usable with CMSimple (classic) and/or CMSimple_XH. But that's not sufficient IMO. CMSimple_XH has evolved over time, so some incompatibilities were introduced from one version to the next. The obviously most important one, was the switch to UTF-8 with CMSimple_XH 1.2. It's often stated that it's enough to convert the encoding of the plugin files to UTF-8 to use ANSI encoded plugins with CMSimple_XH >= 1.2. But that's not the whole truth, as the PHP string routines are not prepared to handle multibyte character encodings. E.g. the often used strlen(), which is expected to return the number of characters a string has, will in fact return the number of bytes a string has. So for a UTF-8 encoded string "€" it will return 3! So a distinction if a plugin works with an ANSI charset and/or UTF-8 is needed as well, as UTF-8 can be selected as charset on CMSimple (classic) too. Another problem, is that declaring compatibility with CMSimple (classic) is not possible, as CMSimple has no pluginloader and a plugin might well depend on the installed pluginloader. So the required version of the pluginloader has to be stated too. And that wouldn't still make it clear, if a plugin will run with CMSimple LE, CMSimple SE, or any other CMSimple package.

So on one hand it's not clear how this compatibility information could be given in a standard way, and on the other (and that's the greater problem) this has to be tested by somebody (probably the plugin author). Consider what that means: he has to install different CMSimple variants and versions, and to test the complete plugin with all this versions.

So it's perhaps best when the plugin developer states the compatibility with different CMSimple variants and versions in the plugin's download info and documentation. An additional overview in the CMSimple wiki might be nice, but that has to be maintained by somebody at least for those plugins, that are not maintained any more by their authors.

@Tata: the .nfo file is meant to provide easily machine readable information about the plugin. You're referring to information easily readable by humans. This is important too. But including it to each important plugin file is IMO prone to errors, as it would be very confusing, if the information in only one file would have been not updated for a new release (developers are humans too ). If it can be automated, it would be a reasonable addition though.

Christoph

[Hugorm]

Christoph indicate a lot of considerations.
At the same time a lot of known information (to very few).

Would it not be posible to make a chart with CMSimple versions on the lefthand side and then have a colum for each plugin on the righthand side (pluginloader being a plugin)?

Could we not start by showing the actually working versions at pressent and then expand as we find time?

Could the information be found by machine it would be easier. Many combination have to be testing though.

Hugo

[cmb]

Hi Hugo,

I really would appreciate, if there would be an extension repository for CMSimple components (Plugins, Templates etc.) like it's the case for many other CMSs, e.g. http://extensions.joomla.org/. Plugins would be presented by category, newest uploads and by popularity (perhaps even by user rating). This would make things a lot easier for users. And in each plugin description information about the compatibility could be given. If this information would be given in a standard way, plugins could even be filtered for a particular CMSimple variant and version.

And this would things make easier for developers and designers too. Currently new plugins are presented in the forum, in the wiki, some in the xh-wiki. But as neither the wiki nor the forum support the presentation of components in a suitable way, it requires quite some additional effort to make this information available manually. E.g. I've begun to add new plugin categories to the wiki, and to provide some feature comparison tables. But it takes a lot of time to check which features are supported by plugins written by others.

But many things could be done semi-automatically, if we had a central repository. Everybody who will present his plugin, has to fill out a form with required information: compatibility, categories, license, download and demo links, description etc. The rest could be done by a software.

So, is anybody aware of a freely available software (preferably OS) to manage such an extension repository?

Christoph

[Phrax]

Hi all,

concerning versioning and dependencies of the plugins I would stick to standardized class-based methods. The pluginloader - as far as I know - goes through all plugins he can find and includes given files and depending on the files builds the plugin navigation bar. You could include a class in admin.php or index.php with standardized name, so if the plugin itself and so the folder is named "myplugin" the class could be "Myplugin" This class could contain functions giving the version number in a appropriate format:

Code: Select all

class Myplugin {
public static function version() {
// return version as string...
}
// or as constant
const VERSION = '1.0.0';
}


There could be other methods added, too:

Code: Select all

// Method to get the name displayed in frontend
public static function name(){
return 'myplugin';
}
// Method to get license
public static function license(){
return 'GPLv3';
}
// Method to register dependencies
public static function dependencies(){
return array(
'jquery4cmsimple',
);
};

// Method to register files.
public static files(){
return array(
'config' => 'config/config.php'
'languages' => array(
'de' => 'languages/de.php'
'en' => 'languages/en.php'
),
// ...
);
}


This would be the beginning of a small registration systemm so the plugins can register with the files and dependencies they need.
Such systems are also used in other applications, especially in MVC based frameworks...

The advantages that I see:
- The pluginloader does not need to seek for all files in the plugin's folder.
- Dependencies are clear and can be handled correctly.
- Version checks would be very easy.
- Currently each plugin ahs its own small 'about' page, mostly there the author, license and a small description is found. These things could be integrated in a nice list of plugins showing name, version, description, license, and a check whether the plugin will run on the current system, so if all dependencies are ok, the CMSimple version is supported etc...

That was just a bit of brainstorming. I have worked with such systems and I like them because everything is structured and standardized.

David

[cmb]

Hi David,

I like the idea of having even more information available in a standardized way. But two things we have to consider:

1. Having those classes in index.php or admin.php means, that other plugins can't reliably get the information, as the other plugin might have been loaded before. So perhaps it's an alternative to put the classes in a separate file that could be read by include_once()?
2. static member functions are not available before PHP 5. So I guess, this might start the discussion about PHP 4/5 again

Christoph

[Tata]

Or maybe to think about some optional compatibility check?
So the Installations would run as they do right now, but the users may optionally be aware that the combination of installed plugins/addons and core may face potentionall problems resulting from the incompatibility.
If a list of plugins will be generated and stored in some standardized file and if it could be checked after any additional installation or upgrade of any plugin,then the user will be always informed and may decide not to install an incompatible thing.