Opened 8 years ago

Closed 8 years ago

#5431 closed Bug (fixed)

CKEditor 3.1.1 and 3.2 have the exact same timestamp

Reported by: Niek Kouwenberg Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.3
Component: Project : CKReleaser Version: 3.2
Keywords: Confirmed Review+ Cc:

Description

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.

Attachments (2)

5431.patch (3.9 KB) - added by Garry Yao 8 years ago.
5431_2.patch (4.3 KB) - added by Garry Yao 8 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 years ago by Frederico Caldeira Knabben

Keywords: Confirmed added
Milestone: CKEditor 3.3
Priority: HighNormal

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.

Changed 8 years ago by Garry Yao

Attachment: 5431.patch added

comment:2 Changed 8 years ago by Garry Yao

Component: GeneralProject : CKReleaser
Keywords: Review? added
Owner: set to Garry Yao
Status: newassigned

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.

comment:3 Changed 8 years ago by Wiktor Walc

Keywords: Review- added; Review? removed

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

comment:4 Changed 8 years ago by Garry Yao

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

comment:5 Changed 8 years ago by 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:

Changed 8 years ago by Garry Yao

Attachment: 5431_2.patch added

comment:6 Changed 8 years ago by Garry Yao

Keywords: Review? added; Review- removed

Have a fuzzy match is ok I think.

comment:7 Changed 8 years ago by Wiktor Walc

Keywords: Review+ added; Review? removed

comment:8 Changed 8 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed

Fixed with [5425].

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy