Release 0.1.5 (or higher)

[130s]

Thanks!

Also please consider making it into ROS Kinetic.

[pschillinger]

Kinetic requires some minor adjustments due to the switch to Qt5. That's not a problem and has already been done on the kinetic branch, but do you know any best practices regarding the versioning? Should I release it under the same number if it only includes the compatibility changes and then keep merging changes like I did it now for your PR? Or is there another way?

[130s]

There's a discussion right in time for your concern. In a nutshell, I recommend to increment the minor version (in this case to make 0.2.x for Kinetic).

[pschillinger]

Incrementing the minor version seems a bit odd to me, it is meant to be used for feature changes in the first place. Indigo/jade and kinetic versions have the same features, they just need to be realized slightly differently because of dependencies. This should be transparent. Also, if I release a new feature for indigo/jade, I would either need to increment the number twice or end up with the same as used for kinetic. The reference posted by Tully in the discussion you suggested mentions another option. It should be possible to use versions like "1.4.0" and "1.4.0+kinetic". By definition, these two are incomparable and none has precedence. If I add a new feature, I can increment both to 1.5.0. Not sure if this is accepted in practice and works with bloom, but looks reasonable to me.

[130s]

I guess that's also a valid concern.

"1.4.0" and "1.4.0+kinetic"

I'm personally not sure if bloom supports it but I think it's worthwhile giving a shot.

[130s]

While I'm curious to resolve #10 (or confirm that #10 isn't actually an issue), I'm personally craving for #5 to be available via DEB.

For the version number, I think you can try making a release with 1.4.0+kinetic. bloom is rigorous enough to be bug-free so it'll tell if your format is not allowed so that you wouldn't mess up rosdistro. It's also possible, however, that bloom would pass but you would still mess, but then you just open a fix PR (ROS buildfarm maintainers are very forgiving :) ).

Only thing I should highlight is that you never want to use the same version for different package content (regardless the difference is feature/config/bugfix/whitespace/etc.) Using the same version number for different code, there won't be any way to tell from each other, which could make debugging unnecessarily harder.

[pschillinger]

Trying to release 0.1.5 right now (indigo, jade) and will continue with attempting to release 0.1.5+kinetic afterwards. Internet is really slow, but I hope it will be sufficient. Otherwise I will try to finish it by tomorrow.

[pschillinger]

Unfortunately, no luck with the +kinetic option:
catkin_pkg.package.InvalidPackage: Invalid package manifest "././package.xml": Package version "0.1.4+kinetic" does not follow version conventions

I will release it as 0.2.0 for kinetic then (same features/fixes as 0.1.5 for indigo/jade).

[pschillinger]

rqt_launchtree 0.2.0 will be in the next update of kinetic as soon as the PR is merged.