backword compatibility check on hrpsys / rtmros_common

[k-okada]

From (fkanehiro/hrpsys-base#210, fkanehiro/hrpsys-base#204, start-jsk/hrpsys#76)
here is my proposal (at this moment) @130s, @garaemon, @snozawa

A: hrpsys-base

1. define "StableRTC" on hrpsys, which includes (seq, sh, fk, co, el, log),

1.1 current "released" robots only uses in these plugins (hiro)
2. keep StableRTC's backword compatibility, even if the version of hrpsys move to 315.2.x, it working with 315.1.x, as long as you uses "StableRTC"

2.1 We have't agreed when we should terminate or change "StableRTC" yet, currently it is just as long as possible...

2.2 https://travis-ci.org/fkanehiro/hrpsys-base/builds/23923220 is the PR to check if newer code is working on 315.1.x (see [1])
3. release current latest version to deb release, so it going to be 315.2.x or 315.3.x, which include latest code as well as backward compatibility to 315.1.x

B: rtmros_common

1. this will compile against latest hrpsys-base, so it going to be 315.2.x or 315.3.x
2. every PR is tested if it works with 315.1.x, using test case defined in 1
3. release current latest version to deb release

The idea behind this is to split the source code into stable and experimental, within one package (directory), and keep stable as stable and working on experimental.
so people who would like to keep backward compatibility, they can use this code as long as you relay on stable code and if you like to test experimental behavior, write code anything you want as long as you did not brake stable code.

[1] backward compatibility test in test hrpsys-base

TEST_TYPE=work_with_downstream

 # check newer version of hrpsys works on current rtmros_common deb package
 # [hrpsys:new] <-> [rtmros_common:old (compiled on hrpsys:old)]

TEST_TYPE=work_with_315_1_10

# check rtmros_common compiled on newer version of hrpsys works with deb version of hrpsys
# [hrpsys:old] <-> [rtmros_common:new (compiled on hrpsys:new)]

[k-okada]

If this idea is ok, then the process is

• prepare for new test code on rtmros_hironx
• merge start-jsk/rtmros_hironx, that brings test code (@130s) -> Fix 81 test for sim 3 rtmros_hironx#86
• run hrpsys-base test code in PR (Compatible with 315 1 cleanup fkanehiro/hrpsys-base#212) again, just to make sure
• update fkanehiro/hrpsys-base to support stableRTC
• merge hrpsys-base test code, this checks downstream compatibility and define stable RTC (@fkanehiro) Compatible with 315 1 cleanup fkanehiro/hrpsys-base#212 also merge PR in start-jsk/rtmros_common to work with stable RTC(Use stable rtc #447)
• update start-jsk/rtmros_common to work with stableRTC
• release 1.0.12 of rtmros_common, this is the last version of current settings
• this can remove HOTFixes in tests code ,
• rtmros_hironx(
  k-okada/rtmros_hironx@689edac#diff-354f30a63fb0907d4ad57269548329e3R66), Remove hotfix rtmros_hironx#93
• rtmros_common rtmros_common(https://github.com/start-jsk/rtmros_common/pull/448/files#diff-dda54a1caa1ccae284a7cdf5f8b4f476R29), add downstream test #448
• hrpsys-base(https://github.com/fkanehiro/hrpsys-base/pull/212/files#diff-b4553af39acae935d505c76e139d4aa3R50), remove hot fix code  fkanehiro/hrpsys-base#216
• add new tag to fkanehiro/hrpsys-base, that's going to be 315.2.0
• merge add downstream test #448
• update start-jsk/hrpsys to use newer fkanehiro/hrpsys-base 315.2.0
• run start-jsk/hrpsys test code again
• run start-jsk/rtmros_common test code again
• rum start-jsk/rtmros_hironx test code again
• add new tag to start-jsk/hrpsys
• and add new tag to start-jsk/rtmros_common again and release hrpsys-base and rtmros_common
• check if start-jsk/rtmros_hironx works with test code

Discussion: this process jumps 315.1.10 to 315.2.0, another idea is to create 315.1.11 that only contains k-okada/hrpsys-base@53de9aa

[130s]

+1
Looks like so much are done already for backward-compatibility test!

One trivial thing,

TEST_TYPE=work_with_downstream
:
TEST_TYPE=work_with_315_1_10 

These names were hard for me to grab the idea initially. But once I noticed that they are rooted from hrpsys-base, they make sense.

[snozawa]

+1
I agree with this compatibility to continuous development.

As for definition of stable RTC,I asked the following question:
fkanehiro/hrpsys-base#212

[k-okada]

DONE!
https://travis-ci.org/start-jsk/rtmros_hironx/builds/24513313