0.2.0 Planning (breaking changes, arch changes)

[kshepherd]

WIP Issue to discuss and plan any breaking changes to introduce in 0.2.

Ideas and comments welcome

• Use the @paginated decorator for all object list responses: do we deprecate the old methods for one release? Simply rename (so _iter is redundant and assumed), breaking 0.1.x usage?
• Some - but not thorough - typing. Enough to fix actual problems but not necessarily satisfy strict linters like pyright
• Other client method structural changes? to avoid huge lists of similarly named methods, can we consolidate some common search operations and return (to do e.g. d.searchFor(ITEM).byMetadata("test")... or d.searchFor(USER).byUUID(uuid).embed('groups'}, or something else that can help us keep the code and usage a bit more tidy and consistent
• Consistent terminology (trying to follow DSpace REST Contract and convention where possible, Python style / convention where it applies instead or is more appropriate)
  • get vs find vs search
  • use of singular and plural in different places
  • one exception to DSpace: I have been stubbornly using "user" instead of "eperson"...
• Consistent usage / expectations for passing 'parent' or 'related' objects to methods -- sometimes we take a full object (and then use its UUID or some other value), sometimes we just want a UUID or a URI for a uri-list. This is annoying from a developer POV. My instinct is we should try to simplify to just require UUID, etc., since not all scripts are working with initialized objects (might have raw lists, text, json, or some var saved another way)
  • In at least one case I've tested for type first, and so allowed both variants. Maybe this is another safe way forward.