[jbosstools-issues] [JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features

[Nick Boldt (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614123#comment-13614123 ] 

Nick Boldt edited comment on JBIDE-26283 at 8/2/18 11:54 AM:
-------------------------------------------------------------

Digging deeper for the case of Forge, and looking at the org.jboss.tools.aesh.runtime_2.0.203.v20180614-0303 plugin which hasn't changed since 4.6.0.Final release [1], we see that the only actual changes are a timestamp stating when the build was done, and the sourceref in the manifest.

* pom.properties comment
!diff-baseline-with-local-build-commented-timestamps.png|thumbnail! 

* manifest.mf eclipse-sourcereference change
!diff-baseline-with-local-build-sourcereferences-cause-problem.png|thumbnail! 

[1] https://github.com/jbosstools/jbosstools-forge/commits/master

So... for this case, bumping version should technically not be required. I wonder if we could add a flag in the compare-version-with-baselines mojo to ignore sourceref deltas in manifest files, or if this means that our process of automatically updating root poms to a newer parent pom ALSO means we have to always bump plugins/features going forward. :(

[~mickael_istria] [~fbricon] [~jeffmaury] WDYT? Should we...

* find a way to not have to bump for projects that haven't changed (except a sourceref change in manifest), 
* don't update to newer parent pom automatically as part of the Final/GA release process, until the project *actually* shows a new commit in master, or 
* just blindly bump to new parent pom AND blindly bump to new x.y.z+1 version too




was (Author: nickboldt):
Digging deeper for the case of Forge, and looking at the org.jboss.tools.aesh.runtime_2.0.203.v20180614-0303 plugin which hasn't changed since 4.6.0.Final release [1], we see that the only actual changes are a timestamp stating when the build was done, and the sourceref in the manifest.

!diff-baseline-with-local-build-commented-timestamps.png|thumbnail!  
!diff-baseline-with-local-build-sourcereferences-cause-problem.png|thumbnail! 

[1] https://github.com/jbosstools/jbosstools-forge/commits/master

So... for this case, bumping version should technically not be required. I wonder if we could add a flag in the compare-version-with-baselines mojo to ignore sourceref deltas in manifest files, or if this means that our process of automatically updating root poms to a newer parent pom ALSO means we have to always bump plugins/features going forward. :(

[~mickael_istria] [~fbricon] [~jeffmaury] WDYT? Should we...

* find a way to not have to bump for projects that haven't changed (except a sourceref change in manifest), 
* don't update to newer parent pom automatically as part of the Final/GA release process, until the project *actually* shows a new commit in master, or 
* just blindly bump to new parent pom AND blindly bump to new x.y.z+1 version too



> Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-26283
>                 URL: https://issues.jboss.org/browse/JBIDE-26283
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 4.9.0.AM1
>            Reporter: Josef Kopriva
>            Assignee: Nick Boldt
>            Priority: Blocker
>             Fix For: 4.9.0.AM2
>
>         Attachments: diff-baseline-with-local-build-commented-timestamps.png, diff-baseline-with-local-build-sourcereferences-cause-problem.png
>
>
> Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstudio/view/devstudio_master/job/jbosstools-base_master/ is red for one week.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)