Preparing for 201x release

[traversaro]

YARP/iCub are preparing for a release for the 15th of June, and iDynTree should merge devel in master and do a new release as well.

General Notification:
Please avoid regenerating matlab bindings in master after #305 as been merged, as it drastically changes the way in which we are handling the bindings.

Things to discuss:

• Version number: until now iDynTree did not followed the release cycle of YARP/iCub, but from now on I think it is necessary to follow it. For simplify our life, I would prefer to use a version number of iDynTree in sync with YARP or iCub
• Add/Maintain a ChangeLog
• How to handle third party dependencies: until now we used the options IDYNTREE_USES_<deps> to enable/disable the dependency of iDynTree on a specific third party component. For the time being, we had IDYNTREE_USES_KDL by default on, but given that iDynTree is increasingly being used in iCub Facility project that do not use the codyco-superbuild, I would prefer to switch the default value of IDYNTREE_USES_KDL to OFF, as we already did for the devel branch. This should not affect the user of the superbuilds, for which the value of IDYNTREE_USES_KDL will still be set to ON (or not) depending on the superbuild
• Other things that we want to solve/do before the release?

[traversaro]

cc @francesco-romano @DanielePucci @diegoferigo @fjandrad @pattacini @nunoguedelha @S-Dafarra @gabrielenava

[traversaro]

I think we should merge all open PRs before the release.

[traversaro]

For the version number, I think we can sync with the icub-main one, and use v1.8.0 from the next release.

[francesco-romano]

Honestly, I would prefer to have our own version number...

[traversaro]

I see no advantage in having our own version number, but I am open to other suggestions.

[nunoguedelha]

What I've seen in Release Engineering, and it seemed to be a good practice, is having a version number for each component / library and an "Integration" version number for the superbuild, connecting all the components/libraries together.
This allows to handle dependencies while letting each component follow its own rhythm of releases.
Of course we can, and probably should use the same format, and agree on common versioning convention, if it's not already done.

[traversaro]

For the version number, I think @diegoferigo should decide, just because I don't want to decide on this. : )

[traversaro]

Once we decided on a version number, we can roll out the ChangeLog and finally release the new version.

[diegoferigo]

I don't think this decision should be mine, however, this is a recap of the current status of our software:

• yarp gazebo-yarp-plugins 2.3.68
• ycm 0.2.2
• icub-main icub-firmware robot-configuration 1.6
• icub-firmware-shared 0.2.1
• robot-testing 1.2
• idyntree 0.4
• codyco-modules 0.1

As you see, we have no policy at all. With today's release, idyntree will be even more standalone than ever, and in my humble opinion it doesn't have much sense for the time being aligning it randomly to any project. If in the future a more strict versioning will be enforced for our ecosystem, we will adapt accordingly. Said this, @traversaro if you think we reached a decent API stability, we can bump to 1.0, otherwise, if we are close and with the next release we plan to freeze or at least to minimize API changes, 0.9 could work. Third option, postponing this discussion and go with 0.5. Opinions?

[traversaro]

I don't think this decision should be mine

I think it is a good exercise, if @DanielePucci agrees. : )

Regarding the current status:

• ycm and robot-testing are indeed independently released,
• icub-firmware-shared is actually now adopting the icub-main release numbering (see icub-firmware-shared version catching up with iCub version? community#20)
• codyco-modules version is not properly managed, and it has no master/devel branch, so it is a perpetual rolling release at the moment.

Anyhow, no problem in having our own release naming scheme, probably we will need at least to keep the odd/even stability style.

[traversaro]

For reference, this is the discussion in which I argued for all icub repos to share the same version number: robotology/icub-main#339 .

[traversaro]

After f2f meeting, we agreed on a version number of 0.8 for this version of iDynTree.

[DanielePucci]

I do agree :)

[diegoferigo]

@traversaro
Do you have a changelog draft (at least in your mind)?

[traversaro]

I started a document following YARP style in https://github.com/robotology/idyntree/blob/devel/doc/releases/v0_8.md . For the 0.8 is quite simple, but I hope that in the future we can maintain it for each PR (i.e. each PR should document its changes).

[diegoferigo]

each PR should document its changes @traversaro

I always agree for distributing the effort in a long timespan

[traversaro]

There are several important class that are under heavy modifications such as InverseKinematics and BerdyHelper . I propose that we wait some of these modifications before releasing the new version of iDynTree .

[diegoferigo]

I agree with you, also considering that we lost the yarp freeze train for this time.

[traversaro]

We need some of the new classes handling conversion from and to DH chains in WB-Toolbox, so I think it is time to finally release the latest version of iDynTree devel in master.

I think we should properly mark the parts of the library that we expect to change in the documentation as such, to avoid more freedom in releasing iDynTree .

[traversaro]

I added a few notes for the experimental classes in #376 , once we merge it we can relase iDynTree 0.8 .

[traversaro]

iDynTree 0.8 released in #377 .