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)."

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 wrote:
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...

Last edited by yvolk on Thu May 24, 2007 2:02 pm, edited 1 time in total.

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?

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.

ianmac wrote:
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...

yvolk wrote: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!

yvolk wrote: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!

..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.

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...)

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.

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.

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.

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

Last edited by yvolk on Wed Jun 06, 2007 12:07 pm, edited 1 time in total.

yvolk wrote:
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.

Last edited by Jinx on Wed Jun 06, 2007 12:25 pm, edited 1 time in total.

yvolk wrote:
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).

Jinx wrote:
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

You do not have the required permissions to view the files attached to this post.

@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

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

You can have programs written fast, well, and cheap, but you only get to pick 2 ...

"I love deadlines. I like the whooshing sound they make as they fly by." Douglas Adams

CirTap wrote:
@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!?

Last edited by yvolk on Wed Jun 13, 2007 8:17 pm, edited 1 time in total.

CirTap wrote:
@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:

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

You can have programs written fast, well, and cheap, but you only get to pick 2 ...

"I love deadlines. I like the whooshing sound they make as they fly by." Douglas Adams

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.

bambii7 wrote: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.