feat: new delete object tags function

[rpenido]

This PR adds the delete_object_tags to the oel_tagging api. This method will be used to clean the object tags applied to an object on its deletion, for example.

[openedx-webhooks]

Thanks for the pull request, @rpenido! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[rpenido]

@ChrisChV I think this is ready to review

[ChrisChV]

@rpenido Looks good :+1: Could you bump the version of the package so @pomegranited can merge and create a new tag?

• [X] I read through the code and checked the tests.
• [X] I ran the tests

[rpenido]

@ChrisChV Done 85f1111bb12114b530eb27937a3c90f18080a454!

PS: I saw that we were bumping the patch version instead of minor for new backward compatible functionalities (which is not exactly semver). Is it ok to bump the minor version now, as this is not a bugfix?

[pomegranited]

@rpenido

PS: I saw that we were bumping the patch version instead of minor for new backward compatible functionalities (which is not exactly semver). Is it ok to bump the minor version now, as this is not a bugfix?

I've been thinking about it like this: The MVP release of the openedx_tagging will be 1.0 -- until then, this library isn't really "in production use". So everything we're doing to support that MVP is still a patch version.

Does that make sense to you and @ChrisChV ? I'm happy to be corrected here.

[rpenido]

From SemVer docs:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

FAQ:

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

I re-tagged it as 0.1.4, following the previous convention! :smile:

[openedx-webhooks]

@rpenido 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.