[forge-dev] Forge 1.1.0.Final

[ggastald at redhat.com]

Hello Paul / Koen,

Yes, I totally agree with you guys. I'll fix that using this strategy. 
However, I wonder what Lincoln has to say about it before I do that.

Best Regards,

George Gastaldi

On 09/20/2012 04:18 AM, Koen Aers wrote:
> This sums up how I expect it to work (I might be biased because of 
> working too much with Eclipse). API's have been broken before for the 
> consumers (plugins) but IIRC we agreed not to let this happen again.
>
> Cheers,
> Koen
>
> Op 20-sep.-2012, om 08:17 heeft Paul Bakker het volgende geschreven:
>
>> Hi George,
>>
>> The problem is that the "marketing" version and semantic version are 
>> not separated cleanly. With marketing version I mean "you must see 
>> this release, it has a new version number so there is a lot of new 
>> stuff!" (nothing wrong with that). A semantic version just says 
>> something about wether APIs are broken or not. The plugin system now 
>> tries to use the version as a semantic version; should or shouldn't 
>> the plugin be compatible with this release?
>> Semantic versioning is something described by the OSGi alliance, but 
>> can be used in any versioning scheme (we have discussed this before 
>> on the mailinglist). It is defined as follows:
>>
>> 1. major --- Packages with versions that have different major parts 
>> are not compatible both for providers as
>> well as consumers. For example, 1.2 and 2.3 are completely incompatible.
>> 2. minor --- API consumers are compatible with exporters that have 
>> the same major number and an equal or
>> higher minor version. API providers are compatible with exporters 
>> that have the same major and minor
>> version number. For example, 1.2 is backward compatible with 1.1 for 
>> consumers but for providers it is
>> incompatible. Consumers should therefore import [1.2,2) and providers 
>> should import [1.2,1.3).
>> 3. micro --- A difference in the micro part does not signal any 
>> backward compatibility issues. The micro
>> number is used to fix bugs that do not affect either consumers or 
>> providers of the API.
>> 4. qualifier --- The qualifier is usually used to indicate a build 
>> identity, for example a time stamp. Different
>> qualifiers do not signal any backward compatibility issues.
>>
>> So the question is: are there any APIs changed related to plugins? In 
>> the case of plugins they will be mostly consumers (plugins use Forge 
>> APIs, but won't implement them most of the time) so only major 
>> changes (that break consumers) matter.
>>
>> The minor version update we want to do for this Forge version implies 
>> that consumers (plugins) will not be broken. First of all we should 
>> decide if this is correct or not, but I expect it is. Next I think it 
>> would make sense the plugin system to only look at major version 
>> changes, because that's when plugins will break.
>>
>> Cheers,
>>
>> Paul
>>
>>
>> On Sep 20, 2012, at 0:31 , ggastald at redhat.com 
>> <mailto:ggastald at redhat.com> wrote:
>>
>>> Hello,
>>>
>>> Forge 1.1.0.Final is on the staging repository, ready to be 
>>> released. However, when I tested installing any plugin (arquillian 
>>> for example) I get the following message and the plugin is ignored :
>>>
>>> Not loading plugin [org.arquillian.forge.arquillian-plugin] because 
>>> it references Forge API version [1.0.3-SNAPSHOT] which may not be 
>>> compatible with my current version [1.1.0.Final]. To remove this 
>>> plugin, type 'forge remove-plugin 
>>> org.arquillian.forge.arquillian-plugin:1.0.3-SNAPSHOT:1.0.0-SNAPSHOT-a13eaa1a-1d84-45bc-921c-4829dd36c0e9. 
>>> Otherwise, try installing a new version of the plugin.
>>>
>>>
>>> What should we do ? Change each plugin to be compatible with this 
>>> version or change the 1.1.0.Final code to ignore it ?
>>>
>>> Suggestions appreciated,
>>>
>>> Best Regards,
>>>
>>> -- 
>>> *George Gastaldi* | /Senior Software Engineer/
>>> JBoss Forge Team
>>> Red Hat
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-- 
*George Gastaldi* | /Senior Software Engineer/
JBoss Forge Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120920/069fd2aa/attachment-0001.html