<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2012-03-14, at 10:32 AM, Lincoln Baxter, III wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">In order to keep Plugin versioning sane, we should discuss the actual rules of our versioning strategy. From our meeting today, we discussed the following possible initial rules:<br><br><ul><li>Using OSGI versioning system</li>
<li>Plugins referencing older forge API should run on newer Forge versions within the same N release for a version number N.x.x </li><li>Plugins referencing newer forge API should not run on older Forge versions within the same N release for a version number N.x.x <br></li></ul></blockquote>I also think this should incorporate the concept of 'binary compatibility' somehow - i.e. *running* on a given Forge version vs *building* against a given Forge version. Rules can be more lax in the latter case (some things may not build from scratch in face of API changes, but already built versions may work.<br><blockquote type="cite"><ul><li>
</li></ul>Thoughts? Would someone care to explain the OSGI versioning system?<br></blockquote><div><br></div><div>It's a form of Major.Minor.Micro.Qualifier - with qualifiers sorted lexicographically.</div><div><br></div><div>Re: compatibility/versioning, I think that another set of rule you may want to take into account is: <a href="http://apr.apache.org/versioning.html">http://apr.apache.org/versioning.html</a>.</div><br><blockquote type="cite"><br>-- <br>Lincoln Baxter, III<br>
<a href="http://ocpsoft.com/" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com/" target="_blank">http://scrumshark.com</a><br>"Keep it Simple"<br>
_______________________________________________<br>forge-dev mailing list<br><a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/forge-dev<br></blockquote></div><br></body></html>