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

[devel]→[master] Preparation of v1.3.0 #361

Merged
merged 161 commits into from
Oct 4, 2021
Merged

[devel]→[master] Preparation of v1.3.0 #361

merged 161 commits into from
Oct 4, 2021

Conversation

diegoferigo
Copy link
Collaborator

@diegoferigo diegoferigo commented May 31, 2021

Edit: see update on renaming in #361 (comment).


While I'd like to bring Edifice support to the Stable channel, I'm still unsure how to deal the temporary scenar-io name in PyPI introduced in #346. The renaming is currently blocked and is tracked in #359.

What I propose is the following. Move forward with the existing status and document in the release notes:

  • Downstream projects that need to depend on scenar-io that this is a temporary name and it will change in one of the next minor releases.
  • Downstream projects should:
    1. Try to stay updated with our releases and update their projects accordingly.
    2. Continue to depend on gym-ignition as they are already (since scenar-io is new). Read next point for more details.
  • Downstream projects that depend on gym-ignition are not affected by this change and should not perform any action. Also, users should not notice any difference. In fact, the new gym-ignition>=1.3.0 depends on scenar-io and this new package will be installed automatically. Furthermore, the future renaming of Claim the scenario name in PyPI and update the project #359 should not affect these users since the renamed scenario package will replace scenar-io and will be installed similarly as gym-ignition>=1.X.0 dependency.

What do you think @traversaro?

There are few features I'd like to try finalizing before the release:

Otherwise the environment does not source the setup.sh script of Ignition
Bump Ignition distribution to Edifice
* Vendor Physics system

gazebosim/gz-sim@1924de9

* Custom Physics features

* Disable using Ignition Dome in CI/CD

* Enable Physics system profiling

* Use upstream components to reset the base velocity

* Fix updating the GUI state with paused run
Simplify passing the physics parameters to the `Server`
…ics_engines

Prepare multiple physics engines support
…ction

Improve how links with no collision elements are handled in contact detection
…ritance

Move inheritance from `ModelWithFile` to `ICubGazeboABC`
Suppress stack trace stderr by redirecting to null
Allow inserting worlds from file containing models
Disable joint velocity limits in the manipulation example
Allow specifying different pos and rot weights for POSE IK targets
…plication

Application of external wrenches: new `empty` method and new Python test
Bump Ignition distribution to Fortress
* Vendor Physics system

gazebosim/gz-sim@4c35f6c

* Custom Physics features

* Revert upstream PR 690

It causes a performance regression when contacts are involved
@diegoferigo
Copy link
Collaborator Author

diegoferigo commented Sep 30, 2021

Waiting only for the ignition-fortress metapackage to land in the stable ubuntu ppa. After this, the CI of the PR that builds and tests the project against a released version of Ignition Gazebo should turn green.

Still in the TODO list before merging:

  • Update the supported distribution of the stable channel in the website

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

Successfully merging this pull request may close these issues.

2 participants