>> 1) If you made changes locally, Eclipse will not automatically
>> install your changed plugins if the version number is the same. You
>> have two options – either uninstall WOLips or cheat and increment
>> the WOLips build version prior to building your local copy. To
>> uninstall WOLips, just delete all org.objectstyle features and plug
>> ins from your eclipse folder. To increment the build server
>> version, open buildserver.version in your projects folder and
>> increment the last number. Note that you will now be "competing"
>> with version numbers from the official build server, so the next
>> official build will not install because you already used the next
>> number, but sometimes it's a quick hack to force an update if
>> you're lazy...
> If this is wrong, I can delete it. Or should this information be
> contextualized into other documents?
This all seems correct to me, except that Eclipse 3.4 (maybe 3.3)
added support for extending your version numbers with additional
values to support precisely what you want to do. So technically
everything said in that statement is true. I don't know what you need
to change in the wolips build files to set your own custom version
number, though.
>
>>> Are the WOLips version numbers only an integer? If I am
>>> understanding the wiki documentation, there is no way to creagte
>>> an intermediate or temporary version number that would conflice
>>> with a subsequent version number. This seems lame. O well.
>> Eclipse plugin versions can be anything. I don't know the exact
>> precedence, but I believe you can add extra strings to that.
>> Whether our build files let you do that, though, is another issue
>> entirely. But you can see lots of eclipse plugins in your plugins
>> folder that do non-numeric version numbers.
> Well, I will try it. If we can use arbitrary numbers, then that
> documentation can be updated.
Well, you would use an extension of our version number ... x.y.z-ray
ms
This archive was generated by hypermail 2.0.0 : Tue Nov 25 2008 - 14:40:45 EST