[
https://issues.jboss.org/browse/JBIDE-15610?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-15610:
---------------------------------------------
note, this is not something new - we've always said if a component is released we
shouldn't reuse the version numbers from previous releases since it makes it extremely
hard to track down errors since the only difference is build timestamp which doesn't
help tracking down which branch/master it was actually built from.
the forge.runtime specific version is a grey-area case since it obviously is not intended
to have any changes in it at all besides which runtime version it contains - but you could
simply add a a or b to indiate it is a rebuild.
For 4.1.1.Beta1: since one forge plugin has bumped, so should they
all
----------------------------------------------------------------------
Key: JBIDE-15610
URL:
https://issues.jboss.org/browse/JBIDE-15610
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: forge
Affects Versions: 4.1.1.Alpha2
Reporter: Nick Boldt
Assignee: Koen Aers
Priority: Blocker
Fix For: 4.1.1.Beta1
[~maxandersen] would prefer that since a single forge plugin (forge.runtime) has bumped
from 1.3.3 to 1.4.1, that all the forge plugins (and their containing features) also bump
at least their service (micro) increment.
Thus:
1.2.0 -> 1.2.1
1.0.0 -> 1.0.1
2.0.0 -> 2.0.1
And in master branch [1], I'm guessing this is wrong:
{code}org.jboss.tools.forge2.runtime_2.0.1.Alpha1-v20130927-1755-B403.jar{code}
Shouldn't that be at version 2.1.0 or 2.0.100, not 2.0.1?
[1]
http://download.jboss.org/jbosstools/builds/staging/jbosstools-forge_mast...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira