[jboss-user] [JBoss Tools] - Future strategy for Tagging JBoss Tools core

[Max Rydahl Andersen]

Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] created the document:

"Future strategy for Tagging JBoss Tools core"

To view the document, visit: https://community.jboss.org/docs/DOC-48351

--------------------------------------------------------------
h1. 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 ?
--------------------------------------------------------------

Comment by going to Community
[https://community.jboss.org/docs/DOC-48351]

Create a new document in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2128]

[Max Rydahl Andersen]

Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] modified the document:

"Future strategy for Tagging JBoss Tools core"

To view the document, visit: https://community.jboss.org/docs/DOC-48351

--------------------------------------------------------------
h1. 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

*
--------------------------------------------------------------

Comment by going to Community
[https://community.jboss.org/docs/DOC-48351]

Create a new document in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2128]

[Denis Golovin]

Denis Golovin [https://community.jboss.org/people/dgolovin] commented on the document

"Future strategy for Tagging JBoss Tools core"

To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48351#comment-11555

--------------------------------------------------
Submodules can be used to track it. We need:
# repository with submodules that points to released jbosstools components
# in repository we can have jbosstools-${major}.${minor}.${patch}-${label}*x* branches for work in progress and jbosstools-${major}.${minor}.${patch}-${label} tags to mark releases

Here what I use to track all jbosstools repositories https://github.com/dgolovin/jbosstools-fork-submodules https://github.com/dgolovin/jbosstools-fork-submodules. It let me do several things without writing additional scripts:
1. I can sync my forks with upstream repositories
2. I can build any version of jbosstools ( considering we have the same  branches tags for components )
3. I can create new branch/tag in every submodule

all above without additional scripts, it just:

*git submodule foreach 'git ${submodule command}'*

It might have some problems to handle branches when they include different set of submodules, because git checkout would not remove submodule that is missing in target branch.
--------------------------------------------------

[Max Rydahl Andersen]

Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] commented on the document

"Future strategy for Tagging JBoss Tools core"

To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48351#comment-11557

--------------------------------------------------
Why do you say "considering we have the same branches tags for components"  for #2 ?

I read that as then all repos have the same tag (i.e. jbosstools-<something>) but then that brings us back to the current/previous strategy which enforces always tagging/branching when no need.
--------------------------------------------------

[Denis Golovin]

Denis Golovin [https://community.jboss.org/people/dgolovin] commented on the document

"Future strategy for Tagging JBoss Tools core"

To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48351#comment-11563

--------------------------------------------------
"Branches in git are very lightweight: A branch in git is only a reference to a single commit. With its parental commits, the full branch structure can be constructed." So it takes nothing to have it and gives consistency throughout components. We have to build unchanged components anyway as a step to be sure it still compilable and especially for components in the middle of dependency tree.

Actually all components are changed between releases, but changes not always affects eclipse related code, so it is good to have those changes branched/tagged.
--------------------------------------------------

[Max Rydahl Andersen]

Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] commented on the document

"Future strategy for Tagging JBoss Tools core"

To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48351#comment-11578

--------------------------------------------------
Not following why branches in git are lighweight affects anything ? its what makes things tolerable right now; but would be even nicer if we didn't have to do it so often ;)

About components then I don't see any changes needed in the components that does not affect the eclipse related code - what are those ? The only change I can recall is the parent pom reference but that is just an old/legacy requirement. It does not need to be updated between builds.

And yes we can still compile from the tag/branch - to ensure things are building but if nothing breaks we don't need to update the actual published plugin.

That is what using Tycho's "Reproducible Version Qualifiers" is for, see wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers
--------------------------------------------------