How to automate Joomla version check?

[yvolk]

As I can see searching the forum, many developers face the problem of version compatibility, e.g. between some Extension and Joomla! core. As I've found out, in a case of a problem, developer asks user something like this: "Can you check the build number showing in changelog.php?" 
I'm sure, you've got a clue of what I'm proposing: create a standard way to check versions for Joomla! core AND all installed components... (I wanted to add "patches" also, but maybe life will be too simple in this case  )
As a starting point I propose to add some global method/variable... to check version of Joomla! core. The simplest way is to define JoomlaCoreVersion variable in changelog.php, so it will be visible both to human beings and to program code.
So, I will add something like this to my component: "Oops! To use yvComment extension you have to install Joomla! 1.5 build XXXX or newer. (Current build of Joomla! core is YYYY)."

[webamoeba]

Can't you use the JVersion class? (joomla.version)

It's even got a isCompatible() method

[yvolk]

Can't you use the JVersion class? (joomla.version)

It's even got a isCompatible() method :)

Thank you, this is something, but:
- JVersion shows only one version: of Joomla! core only;
- even for Joomla! core it doesn't include build number into comparison AND
  $BUILD variable is not an integer (as it description states) - it is a string:
The code:
  jimport('joomla.version');
  $version = new JVersion();
  echo 'Build="' . $version->BUILD . '"
';
Returns:
  Build="$Revision: 7357$"
so I have to write my own function to compare versions, including build number 

I looks like there is a bug either in the BUILD variable value or in its description:
---
  /** @var int build Number */
  var $BUILD = '$Revision: 7357$';
---

[ianmac]

Why would you want to design to a certain build?

Just design to beta 2 and it will be compatible with any beta 2 or newer version of 1.5.

Ian

[yvolk]

Why would you want to design to a certain build?
Just design to beta 2 and it will be compatible with any beta 2 or newer version of 1.5.

I want to design to a certain build of software component, e.g. Joomla, because Joomla!, like any other system, has bugs, that are eventually fixed in certain builds. And it will always have new bugs...

Now I have very pragmatic need: my extension uses "Pagination" feature of Joomla!, that is buggy just in Beta 2 and that was fixed in some more recent build after Beta 2. I don't want to waste time of myself and of my users, writing me: "Pagination in your extension doesn't work..." or even "Your extension doesn't work at all". Instead, I want them to immediately have clear diagnose of the problem with my advice of moving to the certain (tested by myself) or newer build...

Alternate way of developing software for Joomla! would be to stay with Beta 2 and write everything, that is buggy, by myself, don't using built-in Joomla! features. This way will lead me to the unmaintainable piece of code...

[ianmac]

okay...

But I don't think you would want your users using beta software, right?

So the JVersion class should always give you the information you need.  If a bug is found and fixed, then the fix will be put into the next maintenance release, which will at some point be something like 1.5.1, 1.5.3 etc etc.

So you would just have to check for the .3 or whatever, which should be present in JVersion, is it not?

Ian

[yvolk]

But I don't think you would want your users using beta software, right?

Maybe I will prefer to use beta software in some cases, e.g. for applications, that are not "business-critical"  . See these Tim O'Reilly's words about Web 2.0:

Users must be treated as co-developers, in a reflection of open source development practices (even if the software in question is unlikely to be released under an open source license.) The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta," in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a "Beta" logo for years at a time.

So the JVersion class should always give you the information you need.  If a bug is found and fixed, then the fix will be put into the next maintenance release, which will at some point be something like 1.5.1, 1.5.3 etc etc.

So you would just have to check for the .3 or whatever, which should be present in JVersion, is it not?

I will check the whole version number, including that ".3 or whatever" and not only ".3"  . I only want to stress, that these "version increments" should be frequent enough...

[webamoeba]

I only want to stress, that these "version increments" should be frequent enough...

They should only be as frequent as is required. I'm not keen on projects which like to chuck out new versions just for 'fun' or because it is their policy. Hopefully there won't be too many, a large number suggests many bugs!

Just to clarify version increments:

major.minor.patch

[yvolk]

I only want to stress, that these "version increments" should be frequent enough...

They should only be as frequent as is required. I'm not keen on projects which like to chuck out new versions just for 'fun' or because it is their policy. Hopefully there won't be too many, a large number suggests many bugs!

I remember reading "Agile Software Development" by Alistair Cockburn:

..The question is, how long should the delivery increments be?
The correct answer varies, but project teams I have interviewed vote for 1-3 months, with a possible reduction to two weeks and a possible extension to four months.
It seems that people are able to focus their efforts for about three months, but not much longer. People tell me that with a longer increment period, they tend to get distracted and lose intensity and drive.

- These words were written 7 years ago. Today delivery periods must be shorter. I personally like 2 - 4 weeks periods.

[yvolk]

I've created the Bug Tracker Item for this issue. The Bug Tracker Item was quickly closed with no arguments, but I don't think, that the question is so simple...

I gave my reasons (and citations) in previous messages of this thread in support of my opinion (BTW, other people didn't find my arguments wrong...). This is methodological question and I think that Development team have no right to forbid users of Joomla! to use some alternative approaches to the lifecycle of their systems (in this case, using automatic checking of Joomla!s core build number).

As I stated above, my intention is very pragmatic: to have better support of my users (Administrators of Joomla sites...)

[Jinx]

The build numer is added to the version file when a new package is created, you could use the build number to make compatibility checks. It would not be recommend as I also commented in your bug report.

The only reason why we record the built number or said otherwise the SVN revision number is to easily trackback through SVN to the revision of the package. This is handy for developers who want to check there extensions against different versions, all they need is the SVN revision number of each version so they can check it out and test against it.

If you want to do compatibility checks in the middle of a development cycle that's is up to you, we will not add any features to support that methodology. Our release cycle is clearly explained on the developer site and the version class allows you to check against major, minor and point releases, plus you can also check against development status, again not recommended but possible.

For more info how to do version compares there is a handy PHP function you can use : http://www.php.net/version_compare, it suppport, version and development state comparisions.

[yvolk]

Johan, let's start with simple thing:  there is REALLY a bug in JVersion class, that has to be fixed:
There is a bug either in the $BUILD variable value or in its description:
---
  /** @var int build Number */
  var $BUILD = '$Revision: 7357$';
---
Please, see: this var is described as INTEGER (e.g. '7357'),
but its value is STRING ( '$Revision: 7357$') !
I personally prefer BUILD number to be integer, so it may be easily compared.

Do you confirm, that this is a bug?

[Jinx]

It's more a typo, i removed the use of the $revision $ from the version class already.

[yvolk]

So, this is what we have now:
1. JVersion->BUILD variable is empty string.
2. JVERSION global define is '1.5.0' (and it was the same before Beta 2)
3. JVersion->isCompatible function doesn't allow to distinguish if Joomla! is before or after Beta 2
4. Joomla! Developer Network says: "The Beta 2 release can be downloaded from JoomlaCode.  It is advisable to use the nightly builds or the latest svn code for testing purposes."
5. If I or my users-testers downloaded "Beta 2", "nightly builds" or "the latest svn code" and we have any problem that needs to be figured out, there is NO good way to find, what version of Joomla! we are using, except to check CHANGELOG.php file.

See the code, that I'm using now for version check:

Code: Select all

$Ok = false;
$versionName = 'Very old (Doesn\'t have JVersion Class)';
jimport('joomla.version');
$version = new JVersion();
if (!$version) {
} else {
  $versionName = 'Unknown';
   if ($version->BUILD == '$Revision: $') {
    $versionName = '1.5 before Beta 2';
   } else if ( $version->BUILD == '$Revision: 7357$' ) {
    $versionName = '1.5.0 Beta 2';
      $Ok = true;
   } else {
      $Ok = true;
   }
}
if (!$Ok) {
   echo '<hr><p>Oops! To use <a href="http://yurivolkov.com/Joomla/yvComment/index_en.html" target="_blank">yvComment extension</a>'
   . ' you have to install Joomla! 1.5 build 7357 (1.5 Beta 2) or newer. '
   . 'Current version of Joomla! core is "' . $versionName . '".<br/>'
   . '(yvComment Plugin version="' . yvCommentPluginVersion . '")' . '</p><hr>';
}


Johan, do you consider this situation normal?

Please, Johan, every time packaging Joomla!'s "nightly build", "Beta", etc. , assign JVersion->BULD variable to number, that is equal to the "nightly build number" (or "the latest svn code" if this is applicable...)!
... or I will have to parse CHANGELOG.php 

[Jinx]

Please, Johan, every time packaging Joomla!'s "nightly build", "Beta", etc. , assign JVersion->BULD variable to number, that is equal to the "nightly build number" (or "the latest svn code" if this is applicable...)!
... or I will have to parse CHANGELOG.php 

If you build me a built script that does that, I would be happy to use it. In the mean time I'm not going to waste the time of the development working group on this. That may sound harsh but that's the way it is. You wanna see somerthing changed, propose a change, send in a patch or propose code to help address the problem. Just demanding or begging simply won't work.

[yvolk]

Please, Johan, every time packaging Joomla!'s "nightly build", "Beta", etc. , assign JVersion->BULD variable to number, that is equal to the "nightly build number" (or "the latest svn code" if this is applicable...)!
... or I will have to parse CHANGELOG.php 

If you build me a built script that does that, I would be happy to use it. In the mean time I'm not going to waste the time of the development working group on this. That may sound harsh but that's the way it is. You wanna see somerthing changed, propose a change, send in a patch or propose code to help address the problem. Just demanding or begging simply won't work.

As you may remember, I've implemented transliteration, when you suggested...
I'm ready to implement this addition to the "build script", that you are using now. Please give me enough information (that existing script plus info, that is needed for me to test my script).

[yvolk]

If you build me a built script that does that, I would be happy to use it. In the mean time I'm not going to waste the time of the development working group on this...

Johan, I didn't receive any information from you  , but you may be happy anyway :
I've made a script (JoomlaBuildNumber function), that extracts build number from CHANGELOG.php. So it may be used in JVersion class (during its initialization) to set value of $BUILD variable.
But I've done more: I've created function (called fileBuildNumber), that extracts build number from ANY Joomla! file... I suggest you insert this function as public function of JVersion class for completeness.

For those guys, that don't want to wait for Joomla! Dev team to insert this code into the core: please see the above mentioned JoomlaBuildNumber and fileBuildNumber functions in the attached file: testJoomlaBuildNumber.zip

[CirTap]

Hi,

@Jinx: woudn't it be enough to add the SVN $Rev$ tag to the BUILD property?
  var $BUILD = '$Rev$';
Like SVN would update the $Id$ tag it'd update the $Rev$ tag automagically; just "touch" the file, and there'd be no need for manual edit/update of JVersion.

@Yvor: I doubt that your "general purpose SVN revision sniffer" will make it into JVersion, as it's not the job of JVersion to provide version details for every of the ~ 3600 files in Joomla! How's this function supposed to be used and by whom, anyway?
Will your component contain a feature that scans the J! directories to report each revision, or do you want the user to write a script and pass in the filename -- would be faster to have him open the suspicious file in questioin, and look at its header.
Don't get me wrong: I totally understand your motivation, and *why* you believe this might become essentional information.

You may certainly consider the revision of CHANGELOG to be the "built number" of Joomla, but that won't work. *Each* file has it's own revision number, some have the same, most do not, and it will only get updated from SVN if a file has changed.
You can see files in Joomla that haven't been updated for a long time and their revision is nowhere near the rev. you'd get from parsing CHANGELOG -- or any other file for that matter. Depends on when they've been commited.

If you do a checkout or update from SVN doesn't mean that the CHANGELOG has been updated, too -- and you'll end up with more recent "versions" - in your terms - for some files than the CHANGELOG would suggest.
- the dev's don't log every micro change they commit
- there are projects/files in the very same repository increasing the "global" revision number

Right now my current worling copy tells me CHANGELOG is @ Rev 7697 - I'll update now ...
Ok, my SVN client says: At Rev. 7733.
Let me pick a random file from the list of updated files... /components/com_poll/router.php ...
  @version  $Id: router.php 7708 2007-06-09 16:27:20Z jinx $

Your clients/users may do the very same thing. Which "number" would you want to be mentioned?
You finally end up looking at the revion of one particular file that's probably fishy, and the users may open them easily in any text editor.

Have fun,
CirTap

[yvolk]

@Jinx: woudn't it be enough to add the SVN $Rev$ tag to the BUILD property?
   var $BUILD = '$Rev$';
Like SVN would update the $Id$ tag it'd update the $Rev$ tag automagically; just "touch" the file, and there'd be no need for manual edit/update of JVersion.

It looks like some author of JVersion had the same in mind, when (mis)typed:
   var $BUILD = '$Revision: $';
that was changed later by another person to:
   var $BUILD = '$Revision: 7357$';

... but, as I understand, this file needs to be "touched" (by script, that builds package?) before every build of Joomla!'s package!?

[friesengeist]

@Jinx: woudn't it be enough to add the SVN $Rev$ tag to the BUILD property?
  var $BUILD = '$Rev$';
Like SVN would update the $Id$ tag it'd update the $Rev$ tag automagically; just "touch" the file, and there'd be no need for manual edit/update of JVersion.

It looks like some author of JVersion had the same in mind, when (mis)typed:
  var $BUILD = '$Revision: $';
that was changed later by another person to:
  var $BUILD = '$Revision: 7357$';

... but, as I understand, this file needs to be "touched" (by script, that builds package?) before every build of Joomla!'s package!?

Why so complicated? That would mean that every developer had to commit the version.php file with each commit. A nightmare, if you ask me (Unless you are only talking about full versions, like Beta, RC etc.).

Ever heard about SubWCRev? If you are not using TortoiseSVN, probably not. It's a command line utility that scans your working copy for the last updated revision, and optionally replaces specific strings in files with the correct versions.

So the build utility that generated the nightly builds would have to do something like this:

Code: Select all

subwcrev . libraries/joomla/version.php libraries/joomla/version.php
"copy version.php to the package"
svn revert libraries/joomla/version.php


And version.php needed to look like this:

Code: Select all

   /** @var int build Number */
   var $BUILD       = (int) '$WCREV$';


TortioseSVN is only available for Windows, but there is a port of the SubWCRev utility to other platforms:
http://svnwcrev.tigris.org/

[CirTap]

... but there is a port of the SubWCRev utility to other platforms:
http://svnwcrev.tigris.org/

nice, I wasn't aware there's a Linux port. great thanx!
I mentally supplanted it since I never found a practicaly application of it for *my* projects and the ppl. i work with, 'cos its been Windoze-only. Since it deals with it's own set of tags the "others" couldn't update, would have left me in maintaining them ...
Apparently this has changed -- gotta rethink the usage of this, hehe.

Have fun,
CirTap

[bambii7]

Sorry to be posting on an old thread. But having access to a version number is extremely useful. I know both Mootools and SilverStripe have this, I can't say if Magento has it but I'd guess yes.

There are many reasons. Like yvolk has been pointing out, checking for a version to see if you need to use a work around for a bug.

I want to replace the old Mootools. Which is easy enough to remove (and great that Joomla 1.6 is switching to Mootools 1.2) But would be fantastic to reference a $version var to check if you need bother removing.

[ianmac]

Sorry to be posting on an old thread. But having access to a version number is extremely useful. I know both Mootools and SilverStripe have this, I can't say if Magento has it but I'd guess yes.

There are many reasons. Like yvolk has been pointing out, checking for a version to see if you need to use a work around for a bug.

I want to replace the old Mootools. Which is easy enough to remove (and great that Joomla 1.6 is switching to Mootools 1.2) But would be fantastic to reference a $version var to check if you need bother removing.

$version = new JVersion;
echo $version->RELEASE; // 1.5
echo $version->DEV_LEVEL; // 15 (for the current 1.5 version)

Ian

[bambii7]

Thanks Ian, that does help. Especially in my current situation with Mootools.