Issue 165 in rtm-ros-robotics: Decide versioning policy of openhrp3 and hrpsys

[rtm-ros-...@googlecode.com]

Status: Accepted
Owner: kei.ok...@gmail.com
CC: gm130s
Labels: Type-Enhancement Priority-Medium

New issue 165 by gm130s: Decide versioning policy of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

(Not actually a defect)

Continued from
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=159

Ideally openhrp3 and hrpsys maintains the version that can indicate that
they are related (hrpsys depends on openhrp3).

Temporarilly both openhrp3 and hrpsys are set 0.0.1.


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[rtm-ros-...@googlecode.com]

Comment #1 on issue 165 by gm130s: Decide versioning policy of openhrp3 and
hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

BTW, for the version of both openhrp3 and hrpsys, that are currently 0.0.x
due to this discussion, I'm tempted to raise them up to something more
mature. 1.0.x or so. Both of them are 3.x in their original dev, and having
0.0.x gives bad impression to the ROS users w/o reality.

If this sounds good I'll release 1.0.3 (which is still temporary. Needs
this ticket resolved in the end) or so soon.

[rtm-ros-...@googlecode.com]

Comment #2 on issue 165 by kei.ok...@gmail.com: Decide versioning policy of

openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

It easy to understand that ros package have same version as original dev
have.
rosversion -d openhrp3
3.1
seems very reasonable for openhrp3 users

[rtm-ros-...@googlecode.com]

Updates:
Owner: iisaac.s...@gmail.com
Cc: -gm130s kei.ok...@gmail.com

Comment #3 on issue 165 by gm130s: Decide versioning policy of openhrp3 and
hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Agreed, so I'll release:

openhrp3 0.0.2 --> 3.1.2
hrpsys 0.0.2 --> 3.1.2


This way, minor version matches their upstream version.

I think that always adjusting minor version (MAJOR.MINOR.PATCH) to their
upstream, and ROS version only increments patch version makes sense.

[rtm-ros-...@googlecode.com]

Comment #4 on issue 165 by kei.ok...@gmail.com: Decide versioning policy of

openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

いや，upstreamでPATCHバージョンまできまっているので,ROS側はそれに従うだけに
するのがいいです．hrpsysユーザからすると見たこともないバージョンが出てくるの
はびっくりします．
OpenHRP3の3.1.1と3.1.2というのは，upstreamで決まっているというのがユーザ側の
認識です．

[rtm-ros-...@googlecode.com]

Updates:
Status: Started

Comment #5 on issue 165 by gm130s: Decide versioning policy of openhrp3 and
hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Summarizing an offline discussion between Okada-sensei:

Conclusion: ROS packages of these RTM-based libraries preferably correspond
to the same version number

Rationale:
- More intuitive for users if the ROS packages versioned the same to their
mainstream libraries.
- People can get confused if the different version numbers exist between
mainstream and in rtm-ros/us that we might have forked the mainstr. and
been maintaining it, which is false.
- Avoid distributed repositories of the same library that don't get merged.

How to implement the plan:
- Ask mainstream maintainers to release more frequently (which has started
working gradually for some repositories)

Option didn't work out:
- Create an ROS interface/wrapper package (just as how Gazebo, pcl are
interfacing with ROS) --> since we are NOTdepending on external libraries
and instead we install the mainstream within our ROS packages (#1)
- Use different versioning scheme on our end --> as already explained
above, this can't be the option this time.

#1. This can be confusing; our initial and current motivation why we
install mainstream in our packages is that the maintainance of those
repositories are not as active as ours for the moment due to the lack of
capable maintainers, and patches tend to accumulate.

[rtm-ros-...@googlecode.com]

Comment #6 on issue 165 by gm130s: Decide versioning policy of openhrp3 and
hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Okada-sensei,

what versions do you recommend do the following ROS packages have to have
at this moment? I'll go ahead change version of those.

openrtm_aist_core
openhrp3
hrpsys

[rtm-ros-...@googlecode.com]

Comment #7 on issue 165 by kei.ok...@gmail.com: Decide versioning policy of

openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

openrtm_aist -> 1.1.0
cf. `rospack find openrtm_aist`/Makefile.openrtm_aist

openhrp3 -> 3.1.5
https://openrtp.jp/redmine/projects/openhrp/repository/show/3.1/tags/3.1.5
(3.1.5 is just released!!!)

hrpsys -> ???
just a momnet, we're currently working on that, this would be 31.5.0 or
315.0.0
https://code.google.com/p/hrpsys-base/source/browse/#svn%2Ftags

[rtm-ros-...@googlecode.com]

Comment #8 on issue 165 by kei.ok...@gmail.com: Decide versioning policy of

openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

hrpsys is released as 315.0.0
https://code.google.com/p/hrpsys-base/source/browse/#svn%2Ftags%2F315.0.0

[rtm-ros-...@googlecode.com]

Comment #9 on issue 165 by gm130s: Decide versioning policy of openhrp3 and
hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Comment from
https://github.com/ros/rosdistro/pull/2585#issuecomment-28858653 while
releasing openrtm_aist_core 1.1.0 when 1.1.1 is the newest released version:

Are you aware of the problems related to releasing a newer package with
a lower version number?

If yes, I am fine to merge the pull request but that should be a very
conscious decision since it will result in update problems for users if
they already have the package installed.

Let us leave a decision here toward the concern above before we take action
on rosdistro.

In our particular case this time, the only package that demotes the version
number is openrtm_aist_core with the newest version being released just a
few days ago. So besides that the number of users who have updated to the
newest can be small, there are possible problem expected I think of:

P1. Users barely have ways to tell .deb from the old 1.1.0 and new 1.1.0.

P2. I'm not sure if the installation via apt might get corrupted?

For P1, we can tell from the built timestamp of the deb file. If P2
happens, we can respond if there's inquiry for that, probably removing all
debs related to the target deb and reinstall all is a way to fix.

If this sounds good, we can move forward to release a new deb with older
version number.

[rtm-ros-...@googlecode.com]

Comment #10 on issue 165 by kei.ok...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Yes, I think it'ok to proceed.

[rtm-ros-...@googlecode.com]

Updates:
Status: Done

Comment #11 on issue 165 by gm130s: Decide versioning policy of openhrp3
and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Release requests are sent to all openrtm_aist_core, openhrp3, hrpsys for G
and H turtles. You can trace them all from
https://github.com/ros/rosdistro/pull/2585

[rtm-ros-...@googlecode.com]

Comment #12 on issue 165 by gm130s: Decide versioning policy of openhrp3
and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Caveat; apt-get may not install older version even with `--reinstall`
option (at least it didn't do for me so I ended up purging and
re-installing manually).

[rtm-ros-...@googlecode.com]

Updates:
Status: Started

Comment #13 on issue 165 by iisaac.s...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Reopening, and back for now to code.google.com where we can discuss issues
regarding multiple rtm-ros packages altogether.

So there's task requests for new releases into ROS where versions should
stay the same with their original, upstream repositories, to inform the
compliant upstream version (eg. openrtm_aist_core should stay 1.1.0):
- rtshell_core https://github.com/start-jsk/rtshell_core/issues/14
- openhrp3 https://github.com/start-jsk/openhrp3/issues/19
- openrtm_aist_core https://github.com/start-jsk/openrtm_aist_core/issues/20

I would support the same policy that's applied for hrpsys [1]; indicate
upstream version in MAJOR.
- Upstream: 3.1.5
- ROS version: 315.mm.nn

By doing so:
- rtshell_core
- upstream: 1.0.1
- ROS: 1.0.1 --> 101.0.1
- openhrp3
- upstream: 3.1.5
- ROS: 3.1.5 --> 315.0.1
- openrtm_aist_core
- upstream: 1.1.0
- ROS: 1.1.0 --> 110.0.1

[1] https://code.google.com/p/rtm-ros-robotics/issues/detail?id=165#c7

[rtm-ros-...@googlecode.com]

Comment #14 on issue 165 by kei.ok...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

hrpsys version is officially changed to 315.xx.xx,
(https://code.google.com/p/hrpsys-base/source/browse/#svn%2Ftags), and I
think using same number for both upstream and ros package, could avoid
confusion.

[rtm-ros-...@googlecode.com]

Comment #15 on issue 165 by kei.ok...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

it is difficult to determine version number of rtshell_core, because
rtshell is 3.0.0 but rtcctree and rtsprofile are 1.0.0. I think 3.0.0
would be better, because we're usually consider rtshell of veresion 3.0.0.

https://github.com/gbiggs/rtshell/blob/master/rtshell/__init__.py
https://github.com/gbiggs/rtctree/blob/master/rtctree/__init__.py
https://github.com/gbiggs/rtsprofile/blob/master/rtsprofile/__init__.py

[rtm-ros-...@googlecode.com]

Comment #16 on issue 165 by iisaac.s...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

> using same number for both upstream and ros package, could avoid
> confusion.

Personally I haven't seen significant confusion so far -- With a couple of
customers I've talked to I always explained why hrpsys is versioned so
huge, and they thought it's reasonable.

And I'm afraid releasing without version increments isn't common.

That said, however, I can still agree releasing with keeping the same
version with upstream only if:

- Using major version as its upstream compliant (like how hrpsys-base does)
is too confusing for the majority of users.
- There won't be frequent patch releases (I can just persuade packaging
maintainer at osrf for this time's release. I would reference this ticket
then so if sufficient reasoning is provided that would be great).

If so might versions look like the following?

rtshell_core
- upstream: 1.0.0/3.0.0
- ROS: 1.0.1 --> 3.0.0?
openhrp3
- upstream: 3.1.5
- ROS: 3.1.5 --> 3.1.5
openrtm_aist_core
- upstream: 1.1.0
- ROS: 1.1.0 --> 1.1.0

[rtm-ros-...@googlecode.com]

Comment #17 on issue 165 by kei.ok...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

> rtshell_core
> - upstream: 1.0.0/3.0.0
> - ROS: 1.0.1 --> 3.0.0?
> openhrp3
> - upstream: 3.1.5
> - ROS: 3.1.5 --> 3.1.5
> openrtm_aist_core
> - upstream: 1.1.0
> - ROS: 1.1.0 --> 1.1.0

Thanks, that's good for me.

> > using same number for both upstream and ros package, could avoid
> confusion.

> Personally I haven't seen significant confusion so far

if we want ask question on openrtm-users ML, we have to convert our ROS
version to upstream version and ask them. From OpenRTM user's side, the
have no idea why there are OpenRTM related deb packages with unknown
version on ROS repository.

[rtm-ros-...@googlecode.com]

Comment #18 on issue 165 by kei.ok...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

how about moving release repo from start-jsk to tork-a?

[rtm-ros-...@googlecode.com]

Comment #19 on issue 165 by iisaac.s...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

> how about moving release repo from start-jsk to tork-a?

!

That sounds like a good excuse. I'll do.

[rtm-ros-...@googlecode.com]

Updates:
Status: Done

Comment #20 on issue 165 by iisaac.s...@gmail.com: Decide versioning policy

of openhrp3 and hrpsys
http://code.google.com/p/rtm-ros-robotics/issues/detail?id=165

Done https://github.com/ros/rosdistro/pull/3330