Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New release #308

Closed
Tobias-Fischer opened this issue Dec 14, 2020 · 16 comments
Closed

New release #308

Tobias-Fischer opened this issue Dec 14, 2020 · 16 comments

Comments

@Tobias-Fischer
Copy link
Contributor

Hi there,
It's been quite a while since the last release, and great progress has been made since. It would be great to see a new release :).

@jf---
Copy link
Contributor

jf--- commented Jan 5, 2021

yep, also the tags indicating releases are confusing ( 1.3.2 being a year newer from v1.4.0, and inconsistent use of the "v" prefix )

@Tobias-Fischer
Copy link
Contributor Author

Ping @MatthijsBurgh :)

We are running into issues in RoboStack (RoboStack/ros-noetic#89) where OSX builds don't work. This will hopefully be resolved by using pybind11 (as in master) instead of SIP (as in the latest release).

Happy to help out if there is something more required for a release.

@jf---
Copy link
Contributor

jf--- commented Mar 24, 2021

@Tobias-Fischer good call. IIRC ci/cd is not really setup for pykdl. What's happening with conda ros noetic is simply mind bending... @MatthijsBurgh I'm pretty familiar with conda packaging. Less so with conda-forge specifics. Let's see if we can join forces and push for conda-forge ci/cd? Happy to help

@Tobias-Fischer
Copy link
Contributor Author

Note that @wolfv has setup CI for rviz on Linux+OSX+Win using conda and the conda-forge packages (which is much more involved than what we have here). This could be very easily adapted for orocos: https://github.com/RoboStack/rviz/tree/noetic-add-test/.github/workflows

@MatthijsBurgh
Copy link
Collaborator

In my opinion this discussion needs to be split into two things:

  • Compatibility with OSX
  • New release

Compatibility with OSX

we have the PRs #94 and #246. Both are outdated. I don't have any experience with OSX and don't have a system to test on. So the fastest way forward is that you develop it yourself and create a PR. (Including extending CI with OSX) I can help here and there, but I don't have the knowledge and capability to do this. Please create a new issue for this topic.

New release

The responsibility for released is still by @smits and @meyerj. I could bump the version at a certain point, but releasing new debians is not my responsibility.

@jf---
Copy link
Contributor

jf--- commented Mar 25, 2021

I think @Tobias-Fischer & myself both work on osx. Wrt debian, conda!=debian.

Nightly builds are a nice to have, such that you can easily grab a new pykdl version say when a new commit lands in main.

KDL is fantastic, but I think it falls short regarding the OS maxim "release early, release often" for no particularly good reason... So a good call to action...

@wolfv
Copy link

wolfv commented Mar 25, 2021

I think once you tag a release on GitHub, we can work from that. It's not mandatory to have a Debian package for each release. But we cannot really distribute un-tagged versions on the conda channels.

@Tobias-Fischer
Copy link
Contributor Author

Bump on this issue. It would be amazing to get a new version tagged here on GitHub - it's easy and quick to do and would help a lot of people I think :)

@MatthijsBurgh
Copy link
Collaborator

@smits @meyerj I would prefer your input on this one

@smits
Copy link
Member

smits commented May 6, 2021

@MatthijsBurgh I agree with your assessment of the issue, it should indeed be split into releasing and osx compatibility. Currently the Intermodalics team has only been responsible for releasing packages into the ROS 1.x ecosystem using bloom. All other debian packages (ubuntu, ROS2) are made available by others afaik. As long as we properly semantically tag our release versions others can take it from there. I don't mind adding some infrastructure code/files to enable releasing for other OSs, we already have that for other distributions. I also see no reason to not release often, but remember that ABI/API compatibility should be taken into account when releasing into certain distributions. So if a certain release breaks API/ABI compatibility it will mean that it won't be as easy anymore to bring bugfixes to LTS distributions.

@Tobias-Fischer
Copy link
Contributor Author

Just to clarify - @wolfv and I would be happy with a new release with the current state of the repository, as this then in turn would enable us to much easier tackle problems on osx. So for us there is no need for the new release to tackle any issues on osx; we would take it from there and create pull requests that tackle osx compatibility (and any other issues that may or may not emerge when packaging orocos on conda).
TL;DR: More than happy to split release and osx compatibility.

@MatthijsBurgh
Copy link
Collaborator

I think we should release it as 1.5.0 or 2.0.0 As the changes are too big to release it as 1.4.1 IMHO.

@MatthijsBurgh
Copy link
Collaborator

@smits @meyerj What is your opinion on the version number it should be released on?

I want to release this next weekend. When no response received, I will release it as 1.5.0

@smits
Copy link
Member

smits commented May 27, 2021

We try to stick to the semantic versioning scheme, so if the changes are ABI compatible (no recompilation of users required) we could release as 1.4.1, if not then it has to be 1.5.0 (recompilation of users required). If the changes are not API compatible (we should try to avoid this atm IMO) we should release as 2.0.0. See https://semver.org/ for more info.

@Tobias-Fischer
Copy link
Contributor Author

Hi - this issue just came up again in our gitter channel (https://gitter.im/RoboStack/Lobby) - have you had any further thoughts / progress on the new release? It would be really great :)

@MatthijsBurgh
Copy link
Collaborator

I have just released 1.5.0. Any issues regarding OSX should be discussed somewhere else. @Tobias-Fischer @jf--- please take responsibility for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants