Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342025

Summary: BIRT Source code mismatch
Product: z_Archived Reporter: Adam <adambirse>
Component: BIRTAssignee: Birt-Build <Birt-Build-inbox>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: P3 CC: bluesoldier
Version: unspecified   
Target Milestone: 3.7.0   
Hardware: PC   
OS: Windows 7   
Whiteboard: Obsolete

Description Adam CLA 2011-04-06 09:55:37 EDT 
Build Identifier: M20100909-0800

When checking out the source code for 2_6_1_Release from the cvs repository I noticed all the source code plugins have the timestamp 201009151750 where as the plugins installed from the update site are all earlier than this.

e.g. org.eclipse.birt.core_2.6.1.v20100819.

Although I would not expect the timestamps to match exactly, the fact the source code time stamp is a month after the released plugin has made me query if the source code I have checked out does indeed match the the plugins I have installed? 

I hope someone can help clarify why this is the case, and reassure me that the source code I have obtained matches the released version.

Reproducible: Always

Steps to Reproduce:
1. Install BIRT 2.6.1 via update site
2. checkout 2.6.1 source code from the cvs repository
3. Comparing the timestamps shows that the source code was all generated after the update site plugins.
Comment 1 Xiaoying Gu CLA 2011-04-06 23:42:29 EDT 
The timestamps suffix on individule plugin represents the last modifiy date on that plugin, which was created by the development team and may vary from each other. For the release build, it's quite normal that one single plugin have the timestamp suffix that is one month eariler than the final release date, since there might be no bugs found that requires change on that plugin. 

During release cycle, only plugins that have content changed will require suffix upgrade.

For the over-all release tag, build team will create the release tag based on the final build id, for example: 201009151750.
Comment 2 Adam CLA 2011-04-07 04:30:41 EDT 
(In reply to comment #1)
> The timestamps suffix on individule plugin represents the last modifiy date on
> that plugin, which was created by the development team and may vary from each
> other. For the release build, it's quite normal that one single plugin have the
> timestamp suffix that is one month eariler than the final release date, since
> there might be no bugs found that requires change on that plugin. 
> 
> During release cycle, only plugins that have content changed will require
> suffix upgrade.
> 
> For the over-all release tag, build team will create the release tag based on
> the final build id, for example: 201009151750.

Does that mean that I can guarantee that the source code I check out from the cvs repository (version 2_6_1_Release_201009151750) exactly matches the V 2.6.1 plugins installed from the update site? even though the source code is timestamped with a later date.

Many thanks

Adam
Comment 3 Xiaoying Gu CLA 2011-04-07 04:47:50 EDT 
Yes, the release tag 2_6_1_Release_201009151750 should be identical to the code that you downloaded from update site. 

The timestamp of plugin suffix might be earlier than the release tag but will not later than it.