Skip to content

LinkAhead rename lvl 0

Henrik tom Wörden requested to merge f-linkahead-rename-0 into dev

Summary

LinkAhead Rename; First step with no action required for users.

Focus

Due to the renaming the 'Changes' tab in this MRis basically useless. Please have a look at the changes in !113 (closed) instead. The branch of this MR is created from the other one by renaming the module and by creating a thin wrapper with the old name.

The main changes are:

  • renaming in docs
  • renamed CaosDBException; deprecated old version exists; catching CaosDBException also catches the new one
  • renamed CaosDBConnectionError; deprecated old version exists; catching CaosDBException also catches the new one
  • old ini paths are deprecated, but still work. The new inis however take precedence over old ones
  • caosdb_admin->linkahead_admin ; both can be used now.
  • changed imports to relative or to linkahead

Test Environment

  • check that the exception test properly and sufficiently tests that the exceptions are properly deprecated
  • this pipeline
  • test manually that you can use both admins scipts and that they are both in the path. The old one creates a warning.
  • manually test the deprecation of the old ini file names and make sure that the content is still considered
  • integration test [dev] against this branch: caosdb-pyinttest!66 (and check that we did test against the correct pylib version)
  • check that there are no unexpected changes necessary in caosdb-pyinttest!66

Merge Procedure

Check List for the Author

Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines

  • All automated tests pass
  • Reference related issues
  • Up-to-date CHANGELOG.md (or not necessary)
  • Up-to-date JSON schema (or not necessary)
  • Appropriate user and developer documentation (or not necessary)
    • How do I use the software? Assume "stupid" users.
    • How do I develop or debug the software? Assume novice developers.
  • Annotations in code (Gitlab comments)
    • Intent of new code
    • Problems with old code
    • Why this implementation?

Check List for the Reviewer

  • I understand the intent of this MR
  • All automated tests pass
  • Up-to-date CHANGELOG.md (or not necessary)
  • Appropriate user and developer documentation (or not necessary)
  • The test environment setup works and the intended behavior is reproducible in the test environment
  • In-code documentation and comments are up-to-date.
  • Check: Are there specifications? Are they satisfied?

For further good practices have a look at our review guidelines.

Edited by Florian Spreckelsen

Merge request reports