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

Bug 355586

Summary:	derby's qualifier increases each build
Product:	[Tools] Orbit	Reporter:	David Williams <david_williams>
Component:	bundles	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	gunnar
Version:	unspecified
Target Milestone:	Indigo SR2
Hardware:	PC
OS:	Linux
Whiteboard:

Description David Williams

2011-08-23 20:09:20 EDT

At least, I think. While creating the Indigo maintenance release build, one common "sanity check" is to build first, just as we released, in which case we would expect all the bundles' qualifiers to stay exactly the same (since, using same cvs versioned bundle). But, derby 10.5.1 (and its source bundle) increased the qualifier, to, apparently, the "build date". For the Indigo release, the version was 10.5.1.1_201105231903. For (the first, test) maintenance build, the version was 10.5.1.1_201108232203. 

I'm not sure what's wrong in this case, I think we do this "partial fourth field" in other cases, and still pick up the cvs tag. My guess would be that the value in the feature.xml file should be 10.5.1.1_qualifier instead of 10.5.1.qualifier ... but, I think we'll have to experiment to see.

Comment 1 David Williams

2011-08-23 20:57:58 EDT

I'll take ownership. I'm trying a test I-build now, trying it with 10.5.1.1_qualifier in the feature.xml file. If that works, it will bake the version 10.5.1.1_v<datetimestamp> so ... I also re-tagged the derby bundle (module) so it would have a "current date" (while the v, in v<datetimestamp> would have made the version "higher" than merely the previous datetimestamp, no matter what it was, (as long as started with an integer) I think it would be confusing to mere humans trying to "read" the qualifier).

Comment 2 David Williams

2011-08-23 23:12:25 EDT

My "experiment" worked. Now bundle is labeled/versioned as 10.5.1.1_v201108232300

I'm going to put this in Indigo maintenance build, too. If we did not, then we
would be in an awkward position where the "maintenance version" would be higher
than Indigo released version and appear higher than Juno version, even though
contents all the same. This way (being in maintenance, and Juno) at least the
version will be the same from now on. 

I have also updated the instructions at 
http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Special_Detailed_Notes_on_the_four_segment_case
(they were a bit ambiguous, at best ... sounding like the "date-time stamp
changing every build was ok ... but have been in the early days :) 


Adding Ryan to CC, since he is "contact" for this bundle. 

Ryan, let us know if there's some history here that requires the other form. (I
can not imagine having a 'v' or not would matter, and pretty important to stay
the same each build. Guess we never noticed before, since been a while since
we've done "maintenance builds").

Comment 3 David Williams

2011-08-31 11:07:04 EDT

I'd miss targeted this originally as "RC2" ... should have been "SR1" ... but, not appears we will not have an SR1, so will retarget as SR2.