Community
Participate
Working Groups
Build Identifier: 20110916-0149 Here's the use case for why this is important and should be flagged. A project has development happening in two parallel streams, one for release A, and the other for release B. The project team plans to ship release A and then later ship release B. Plug-in X exists in both streams and its version in its manifest is 1.2.3.qualifier. Build tools fill in a qualifier based on the time and date of the build after a change has been delivered. So if a change is delivered on December 13th, 2011, the version number would end up being something like 1.2.3.v201112131045. If the contents of the plug-in don't change, its version number doesn't change even though there may be more builds. Now suppose a change gets delivered to stream B on December 13th. The version number of plug-in X is then 1.2.3.v201112131045. If a similar change gets backported to stream A and a build happens on stream A on December 14th, the version number of plug-in X in stream A becomes something like 1.2.3.v201112140826. No further changes get delivered to X in either stream. Now the project team ships release A. In this release, plug-in X has the version number 1.2.3.v201112140826. Months later, the project team ships release B. In this release, plug-in X has the version number 1.2.3.v201112131045, which is lower than the version number in release A. Now, customers who first install release A and then upgrade to release B do not get the correct version of plug-in X. Reproducible: Always
