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.
~Lincoln
On Thu, Sep 20, 2012 at 2:17 AM, Paul Bakker <paul.bakker.nl(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev