0 users online. Create an account or sign in to join them.Users


Symphony's issue tracker has been moved to Github.

Issues are displayed here for reference only and cannot be created or edited.


Closed#121: Version number not saved correctly

It’s quite common for extensions to use “three step” version numbers like 1.0.3. Symphony saves the number of the currently installed version as double in the database which reduces the mentioned version number to 1. Version number with only “two steps” (1.3.) are not affected. I guess this problem is the reason why some extensions use a different format with two digits after the decimal point: 1.03

In my opinion, Symphony should leave all version numbers as they are and should not convert them into a different format, allowing something like 1.0.3-dev or 2.0RC1, too.

See related forum discussion.

allowing something like 1.0.3-dev or 2.0RC1, too

Checking for newer versions might get complicated if you allow all these variations.

What do you think about a timestamp solution then?

Well, Symphony uses PHP’s own version_compare() function that allows all these variations so I don’t see a reason for a custom solution.

I did not know this. Rather cool.

Extension version numbers are stored as strings instead of float. This allows ‘PHP-standardized’ version numbers to be used. This also addresses localisation problems, raised in issue #124, where a comma is used instead of a dot in a version number, resulting in broken SQL when installing said extension. Update script has been updated to include the SQL to alter the sym_extensions table. Closed by 85387065d40a0a2a7ce3065cb31c674856b8fa02

Fairly certain that fixed it. Make sure you run the update script.

This issue is closed.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details