Community
Participate
Working Groups
Now that build identifiers and dependency version ranges are being automatically generated and inserted by Buckminster (see bug 309144 and bug 309141, respectively), we need a replacement strategy that takes such changes into account when determining version qualifiers. Without such a strategy, we could (and, in fact, already have) run into a situation where a newer build cannot be installed even if/when the build identifier and/or (more importantly) dependency version ranges have changed. A possible solution might involve consulting the p2 metadata produced for the previous build when computing the qualifier versions for a new build and using the build timestamp as (a seed for) the qualifier when the resulting metadata for the new build will be different.
A parital fix for this has been committed. Partial, because it is too late in the game for introducing new features and API's. The fix will allow that a p2 repository is used as a reference for a new build. This repository is consulted to see if an artifact contains a generated build id. If it does, a new qualifier will always be generated, regardless of if the source has changed or not. The fix will not look at any other thing. Just the generated build identifer. That's it for Helios. That fix was released to trunk, revision 11449. The absolute first time a reference repository is used, you must build twice and the builds must use different build-ids. The first build will create the reference repository with an additional property that Buckminster will inject. The second build will recognize that property and act accordingly. I'm leaving this bug open since the use of a reference repository when generating qualifiers can be elaborated a lot more.
(In reply to comment #1) > A parital fix for this has been committed. Partial, because it is too late in > the game for introducing new features and API's. > > The fix will allow that a p2 repository is used as a reference for a new build. > This repository is consulted to see if an artifact contains a generated build > id. If it does, a new qualifier will always be generated, regardless of if the > source has changed or not. The fix will not look at any other thing. Just the > generated build identifer. That's it for Helios. That fix was released to > trunk, revision 11449. > > The absolute first time a reference repository is used, you must build twice > and the builds must use different build-ids. The first build will create the > reference repository with an additional property that Buckminster will inject. > The second build will recognize that property and act accordingly. > > I'm leaving this bug open since the use of a reference repository when > generating qualifiers can be elaborated a lot more. Thank, Thomas. So, what is the name of the new strategy and of the property I need to set to the reference repository location?
Note that there is a problem with the timestamp that's being used if/when it's determined that a feature needs a new qualifier. It seems that it's always using Date.now() rather than a single timestamp for the build which, ideally, would correspond with the timestamp upon which the build identifier is based (if applicable).
I made some changes to how Buckminster handles the already present buckminster.build.timestamp. It can now be set to a timestamp in the exact format that is passed by Hudson, i.e. yyyy-MM-dd_HH-mm-ss. The lastModifierGenerator will use this timestamp instead if the property is set. If it isn't, then it's value will be assigned the current timestamp once and subsequent requests will then use that same timestamp. This fix was released to trunk, revision 11456.
