]
Max Rydahl Andersen commented on JBIDE-18837:
---------------------------------------------
[~fbricon] when *should we need to* do this with in a micro release outside development
builds where we are necessarily bumping foundation to get the version updated ?
I'm not following in which case we would ever need such hard lock in ? I assume you
mean for between luna and mars (different release trains ?)
Then A) sure - but the updatesite won't have anything else (not perfect but means wont
have the problem) B) this is not needed for 4.2.1.CR1 afaics ?
because Foundation defines the version of JBoss Tools used to do
ide-config.properties lookup, must enforce it's always updated
-------------------------------------------------------------------------------------------------------------------------------
Key: JBIDE-18837
URL:
https://issues.jboss.org/browse/JBIDE-18837
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build, central, common/jst/core, project-examples
Affects Versions: 4.2.1.CR1
Reporter: Nick Boldt
Labels: respin-a
Fix For: 4.2.1.CR1
When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project
Examples, and NOT update Foundation.core, which means his Eclipse will still think
it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in
examples and central, to force this lock-step updating.
And we need to use the maven enforcer plugin to fail the build if these versions get out
of sync.