<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/05/2013 09:07 PM, Alexey Kazakov
wrote:<br>
</div>
<blockquote cite="mid:5111669D.7010102@exadel.com" type="cite">
<pre wrap="">Hi guys,</pre>
</blockquote>
Hi,<br>
<br>
<blockquote cite="mid:5111669D.7010102@exadel.com" type="cite">
<pre wrap="">I have a question regarding updating plugin/feature version for JBT
4.1.0.Alpha.
Should we just increment N in x.N.y for all the plugins/features
versions which we changed even if it was just a minor bug fixing?</pre>
</blockquote>
I would recommend using these rules
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Version_Numbering">http://wiki.eclipse.org/Version_Numbering</a> , but Max & others
should confirm whether we want to follow them of not:<br>
These rules are, according to the delta between last release and
current work:<br>
* Bugfix: increment micro<br>
* New feature: increment minor<br>
* Broken API (removed or renamed some public methods or classes):
increment major.<br>
However it's an habit that plugin follow also the versioning pattern
of there release train (Eclipse for WTP, JBT for our components).<br>
<br>
<br>
<blockquote cite="mid:5111669D.7010102@exadel.com" type="cite">
<pre wrap="">Should we change Eclipse (wtp, etc.) dependencies in plugin.xml too even
if we don't use any new API from Kepler?</pre>
</blockquote>
No, you shouldn't do it. MANIFEST.MF must contain the "wider"
compatible version range.<br>
<div class="moz-signature">-- <br>
Mickael Istria<br>
Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
by Red Hat</a><br>
<a href="http://mickaelistria.wordpress.com">My blog</a> - <a
href="http://twitter.com/mickaelistria">My Tweets</a></div>
</body>
</html>