[forge-dev] Forge 1.1.0.Final

Lincoln Baxter, III lincolnbaxter at gmail.com
Thu Sep 20 09:55:48 EDT 2012

Hey Paul!

Thanks for the feedback! Where've you been!? :) I agree with you. This is a
very good version scheme and I think we should use it. The only issue is
distinguishing between consumers and producers, but as of Forge 1x, there
are no producers, so this will only be a concern for Forge 2x.


On Thu, Sep 20, 2012 at 2:17 AM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:

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

Lincoln Baxter, III
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120920/246b7787/attachment.html 

More information about the forge-dev mailing list