Our recent move to git caused some confusion on how we tag/branch components in JBoss Tools core components.

Current versioning

To avoid future confusion here are the short version of the current approach:

1. Each component has its own version in manifest.mf/pom.xml
2. The git repositories should use tag/branches based on jbosstools version (jbosstools-<version>x for branches, jbosstools-<version> for tag)
3. In Jira use the jbosstools version for reporting/targeting issues.

The advantage of the above is that git & jira use the same version and no need to juggle multiple versions for git nor for jira queries.

i.e. with a unified tag like "jbosstools-4.1.0.Alpha1" you can find which version is used of a specific component for a specific jboss tools release easily.

Future Versioning

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 ?