On Revert shark

About #1592 (closed) :
What should we do? We have a branch that revert the modification done for the development version of Shark, and we also have a possible release of Shark.
Discussions are open.

I think the initial plan is still good : revert the change on 6.6 and put them in develop. If the new shark release is up-coming, problem will be solved for 6.8 and in the mean-time shark early adopters can work with develop.

Even if shark devs keeps their promise one has to make sure shark debian package is updated. AFAIK, it is maintained by debian-science team. If everything comes nice and clean revert_shark branch becomes useless.

if plan is to hold release until debian updated shark package (in unstable) this works. Otherwise revert_shark branch has to become rc2 or final release. I don't have a strong opinion on release of otb asap but rather to keep support for stable shark whatever version it is..

revert the change on 6.6 and put them in develop

in the mean-time shark early adopters can work with develop

That seems contradictory... I revert Shark in develop nobody will be able to use the new version...

revert_shark branch has to become rc2

I agree with this. A more elaborate scheme can be adopted in order to allow an easier back-port of bugfixes in develop without reverting Shark.

I thought the plan was to revert in release-6.6 and leave develop as-is.

resolved all discussions

added 1 commit

• 3493d8bb - BUG: fix OTB_VERSION_PATCH

Compare with previous version

What is the status of this branch ? Can we merge it and see if dashboard comes clean ?

Note that after we merge this into release-6.6, and after we have released 6.6, we will merge release-6.6 into develop. This will indirectly merge revert_shark into develop which we want to avoid.

After some brainstorming, I think the correct way to handle this is to revert the merge of revert_shark into release-6.6 in develop, just after the merge of release-6.6 into develop. In summary:

git checkout release-6.6
git merge revert_shark # this will produce commit <SHA1>
git tag 6.6 # do the release
git checkout develop
git merge release-6.6
git revert <SHA1> -m i

Where i is the correct parent number (https://stackoverflow.com/a/7100005)

We can even do the revert right after tagging, because we will also need this revert on release-6.6 when Shark package will be updated on Debian side:

git checkout release-6.6
git merge revert_shark # this will produce commit <SHA1>
git tag 6.6 # do the release
git revert <SHA1> -m i
git checkout develop
git merge release-6.6

Then when Shark is updated in Debian, a minor release is enough to update properly our package:

git checkout release-6.6
git tag 6.6.1

Yes even better! (welcome back @gpasero :))

(thanks @poughov )

In order to avoid issues with the reverts, it will be better to merge this branch after other bugfixes. We can use the automatic synchro mechanism in the meantime.

added 1 commit

• 8f854e9a - COMP: allow tests to link with optional deps, no dragged by module lib

Compare with previous version

added 1 commit

• e3e404d4 - COMP: link error with Boost on Windows

Compare with previous version

added 1 commit

• d3ec2d10 - SuperBuild: use official Shark version (for debian)

Compare with previous version

resolved all discussions

added 1 commit

• b68d86d8 - SuperBuild: make sure shark library goes to install/lib

Compare with previous version

merged

mentioned in merge request !160 (merged)