CKEditor 3.1.1 and 3.2 have the exact same timestamp

[Niek Kouwenberg]

Since the timestamp is actually calculated using the release date, and version 3.1.1 and 3.2 have been released on the exact same date, the timestamp for both is the same.

This however defeats the whole purpose of this timestamp: to prevent caching.

Since this cannot be changed now, but might possibly happen again in the future, I would suggest to not only use the release date to calculate a unique timestamp, but also the CKEditor version.

[Frederico Caldeira Knabben]

We may check if the revision number is an option, but I think we'll have the same problem if both local copies of the repository for each version will be at the same time updated to head. If confirmed, the revision number may be an option.

[Garry Yao]

I think it won't happen the case where we'll be releasing two different versions from the same brancn; But it's possible that one is from trunk, another from branch, just like 3.1.1/3.2, it's safe to use the combination of release date + reversion number to create a timestamp.

[Wiktor Walc]

If we compare the result of svn info command that is used to get the revision number in CKReleaser, we'll see that due to the way how SVN works, they're equal in the trunk and 3.3 branch.

trunk:

URL: https://svn.fckeditor.net/CKEditor/trunk
Repository Root: https://svn.fckeditor.net
Revision: 5415 <---------------------
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 5414
Last Changed Date: 2010-04-28 15:38:53 +0200 (—r, 28 kwi 2010)

vs 3.3 branch:

URL: https://svn.fckeditor.net/CKEditor/branches/versions/3.3.x
Repository Root: https://svn.fckeditor.net
Revision: 5415 <---------------------
Node Kind: directory
Schedule: normal
Last Changed Author: garry.yao
Last Changed Rev: 5405
Last Changed Date: 2010-04-27 11:53:10 +0200 (Wt, 27 kwi 2010)

We have two options:

• use "Last Changed Rev" instead (I'm not sure though if this string will change into something else in the future)
• use version number instead as suggested by niek

Right now we're adding ?t=A39E to prevent caching. I think we can safely add at the end version number (without spaces and dots):

• CKEditor 3.1.1 = ?t=A39E311
• CKEditor 3.2 = ?t=A39E32
• CKEditor 3.2.1 Beta = ?t=A39E321Beta
• CKEditor 3.2.1 SVN = ?t=A39E321SVN
• etc.

For stable releases we'll have just 2 or 3 extra characters.

The nightly build will work fine as well because nightly builds from 3.3 branch and trunk will have a different version number (3.3 SVN and 3.2.2 SVN respectively).

[Garry Yao]

Nice catch Wiktor, do you think it's enough to use Last Changed Rev as our reversion number?

[Wiktor Walc]

Yes, using Last Changed Rev should be enough.

I've changed something in the external code used both in a branch and trunk to check the "Last Changed Rev" and it remained unchanged (and different), so it looks like it's exactly what we need.

The only thing that I'm worried about is the inconsistency in the information returned by svn info:

• Revision:
• Last Changed Rev:
• Last Changed Author:

If we're going to use it, I think we should be prepared also for:

• Last Changed Revision:

[Garry Yao]

Have a fuzzy match is ok I think.

[Garry Yao]

Fixed with [5425].