-
Notifications
You must be signed in to change notification settings - Fork 417
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
Comments
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 ) |
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. |
@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 |
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 |
In my opinion this discussion needs to be split into two things:
Compatibility with OSXwe 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 releaseThe 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. |
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... |
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. |
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 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. |
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). |
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. |
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. |
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 :) |
I have just released 1.5.0. Any issues regarding OSX should be discussed somewhere else. @Tobias-Fischer @jf--- please take responsibility for this. |
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 :).
The text was updated successfully, but these errors were encountered: