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

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(a)redhat.com > <mailto:ggastald@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 <mailto:forge-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@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

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