Future Strategy

The disadvantage of the above is it assumes components are always released/rebuilt for each JBoss Tools release.

This is something we would like to move away from requiring to allow for smaller updates (only download what actually changed) and

faster build times (aggregation is faster than always build from source).

What we need to get to a model where:

1. Each component has its own version in manifest.mf/pom.xml
2. The git repositories should use tag/branches based on component version

Is to solve (or ignore following issues:

• Jira ?
  • jira does not have support for versions per component, thus need project per component.
    • How to get query to see which issues are missing/left ?
• Git
  • how to know which version is included in jboss tools release ?
    • can we use submodules to model this ?
    • use eclipse's map file approach ?
    • Something else ?
• Build
  • Find process/build steps to validate version issues
    • Currently we rebuild components and rely on qualifier timestamps to bump to avoid conflicts when installed
      • Advantage: No need for component owners to do anything to get their version included in CI/build
      • Disadvantage: The version tend to not actually be bumped even though it should be. i.e. 3.2.0 to to 3.2.1 between two releases.
  • Don't require rebuilding all components
    • We do have the parts to do this now, but without any good mechanism to reproduce build locally