| [cross-project-issues-dev] Qualifier replacement done in buckminster-based builds |
|
Hello Folks, During a recent buckminster issue[1] discussion with Thomas, I learnt some interesting behaviour about how buckminster works with the qualifier (forth.segment) replacement. This started an interesting discussion which I wanted to share with you to obtain more points of views... Picking some thoughts up from said bugzilla (+ fixing typos ;P ) "This also explains why in spite of not making any change to the source code (I'm doing releng changes), some plugins qualifiers are being replaced with the current date of the build... which I find it an inconvenience, and I'll try to explain that. These suspicious plugins are the tipical plugins which work as branding plugins (used by the features), containing the about information (which includes about.mappings with the build.id). This build information is quite useful to see in our features, and I understand that if the buildId changes, then the plugin is different, then we should change the qualifier to use the current build date. However, if we change the qualifier, in a future software update will make P2 to download a no-necessarily lightweight plugin again, just for updating a simple buildID. IMHO, an inconvenience from the point of view of an updating process. Some solutions: 1- No including build information for our features. 2- Splitting out the about information in a different branding plugin, so that it's just a lightweight branding plugin which gets downloaded during an update process. 3- Making this qualifier replacement behaviour, configurable from buckminster. Although I'm not sure that this is the right solution... 4- Living with the overhead in the update process ;P " I'm wondering how other projects are dealing with this, best practices, advises, any other related concern, etc... Shouldn't the Eclipse projects have the same way to face on this issue ? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=351928 Best Regards, Adolfo. --
|
