FCK class should have a function that returns FCKeditor version and revision

[Wiktor Walc]

Tips: FCKeditor version can be hardcoded, revision can be obtained by adding $Rev$ keyword somewhere inside class definition. I think that this function must be available in FCK class (so that it was possible to check it while loading configuration file), FCKeditorAPI should have similar methods as well.

The problem is that when developing a plugin for other software (like Drupal), it must work with at least two versions of FCKeditor - 2.4 and 2.5. Ideally, it should work with as many FCKeditor versions as possible. Some things change with time (new commands are added, perhaps some other commands are dropped, file location is changing etc.) and to trace those changes I have to use tricks.

For example to check whether I can add 'ShowBlocks' to the toolbar in config located in CustomConfigurationsPath, I check whether FCK.GetData exists (because it was added in FCKeditor 2.5).

Next example: the location of server connectors has changed and I have to use file_exists() tricks to detect the valid path. So we have to add this not only to javascript core, but also to FCKeditor classes in all other languages.

I have set the milestone to 2.5, because the sooner we do it, the less mess we would have in plugins.

[Alfonso Martínez de Lizarrondo]

There's already such functionality in fckeditor.js

FCKeditor.prototype.Version			= '2.5 Beta' ;
FCKeditor.prototype.VersionBuild	= '16848' ;

The only problem is that if you are using the trunk then you get placeholders instead of the proper data:

FCKeditor.prototype.Version			= '[Development]' ;
FCKeditor.prototype.VersionBuild	= '[DEV]' ;

I wish that it could always work, at least keep the VersionBuild during development the same than in the last release (or increased by one), so we can always use that number to check for the new functionality without the extra steps as Wiktor explained.

[Wiktor Walc]

Thanks for explanation. I missed that :-) I looked at FCKVersionMarker and it looks like the only thing we have to do to access VersionBuild is to add there new files (this way we will still have placeholders there in test environment) or...

VersionBuild could be calculated by adding SVN revision to predefined number instead of incrementing it each 6 hours. This way we could still have predefined VersionBuild variable, but also a function that would work even in test environment.

example in PHP to see what I mean:

// @Packager.Remove.Start
function FCKeditor_GetRevision()
{
	$build = '$Rev: 1068 $' ;
	return 16200 + preg_replace('/[^0-9]/', "", $build) ;
}
if (!function_exists('FCKeditor_GetRevision')) {
// @Packager.Remove.End
function FCKeditor_GetRevision()
{
	return '[DEV]' ;
}
// @Packager.Remove.Start
}
// @Packager.Remove.End

The drawback is that we would have to adjust that number (16200) in source files each time we change SVN repository.

[Frederico Caldeira Knabben]

I also agree that it would be nice to have the version and build number in the server side integration files.

It would be also wonderful to have ways to automatically have the revision number updated on commits, but I think we have technical limitations for it. We could at least try to make the releaser get it from somewhere when building the release.

Anyway, all these things would bring a lot of work, and we can't block the 2.5 because of it. So, postponing.

[Wiktor Walc]

My initial proposal was wrong. The $Rev keyword stores the last known revision in which particular file changed in the repository. So it can't be used to calculate the correct revision of the FCKeditor in a trunk anyway.

New idea, use "[DEV] 17566" instead of "[DEV]":

function FCKeditor_GetVersionBuild()
{
	$result = '[DEV] 17566' ;	
	// @Packager.Remove.Start
	$result = preg_replace('/[^0-9]/', "", $result) + 1;
	// @Packager.Remove.End
	return $result;
}

Until now, fckreleaser.php was replacing "[DEV]" with FCKVersionMarker::CalculateBuild(). So nothing is really changed here, we'll just search for "[DEV] \d+" instead of [DEV].

Now to make it fully working in a trunk, one additional step is required:

fckreleaser.php (or another script) must replace in a trunk "[DEV] 17566" with the "[DEV] newVersionBuild"... and commit it to SVN (this is the main drawback of this solution).

This way at least we can have that what Alfonso proposed - VersionBuild is available in a trunk (and increased by one).

I think it can be a good idea to pospone it once again.

[Frederico Caldeira Knabben]

I didn't try the code, but the changes make sense.

A few minor things:

• In the trunk, we should have an special revision number, just like in FCKeditor. Right now, it should be called "CKEditor 3.0 SVN". The real name is set only when creating public releases. So, please change the releaser batch program with the following params:

"CKEditor 3.0 SVN" ckeditor_3.0_svn.zip ckeditor_3.0_svn.tar.gz

• Actually, you could even avoid having both the .zip and .tar.gz file names in the above line. Having only '"CKEditor 3.0 SVN" ckeditor_3.0_svn' would be enough, and that name would be used for both the .zip and .tar.gz files.

• It's wrong to say "the CKEditor". It's a noun, and you should use only "CKEditor" ("version number of CKEditor"). Actually the documentation should say something like "Contains the CKEditor version number.". In this case "the" is not for "CKEditor", but for "version number".

As said... just small details, but the code itself is ok.

[Wiktor Walc]

Fixed all the things above plus:

• simplified (removed) CKReleaser directives in ckeditor_base.js
• shortened %REVISION% into %REV%
• if CKEditor is launched straight from the trunk, the revision property will contain string %REV% and version will be set to %VERSION%.

[Wiktor Walc]

Fixed with [3373] and [3374].