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.
--
|