>> Yes, I know we agreed there would be a stable version so that juno testing is
reproducible. But I was waiting for the 0.2.0 release for that - and then jbosstools-4.0.x
branch of jbosstools-integration-tests would use that. But since I broke it before that,
the solution I came up with for now is to build 0.2.0-SNAPSHOT of RedDeer from a commit
just before I broke it for Juno. (This PR made use of the newly build RedDeer repo:
https://github.com/jbosstools/jbosstools-integration-tests/pull/242 ) Andrej says he
thinks he won't need any more changes for Juno. If they do require changes, we will
create a branch based on this commit. But not sure if we can do anything about the
version.
>>
>> Do you have a suggestion for a better solution in this situation?
>
> then git tag that SHA1 you built as the 0.2 release -
OK, this seems like the best thing to do, so I'll go ahead and do it - release that
sha1 as 0.2.0 and move master to 0.3.0-SNAPSHOT immediately.
> but it just seems like all the versions numbers aren't set in reddeer - i..e
where does it actually say 0.2 in this release?
In all manifests, e.g.
https://github.com/jboss-reddeer/reddeer/blob/master/org.jboss.reddeer.di...
And the parent pom which everybody else inherits the version from:
https://github.com/jboss-reddeer/reddeer/blob/master/org.jboss.reddeer.pa...
And everything in the resulting repo has 0.2.0 as well:
http://download.jboss.org/jbosstools/builds/staging/RedDeer_master/all/repo/
Anything else you're missing?