refactor: DBTP-1766 - version provider

[ksugden]

Addresses DBTP-

---

Checklist:

Title:

• Scope included as per conventional commits
• Ticket reference included (unless it's a quick out of ticket thing)

Description:

• Link to ticket included (unless it's a quick out of ticket thing)
• Includes tests (or an explanation for why it doesn't)
• If the work includes user interface changes, before and after screenshots included in description
• Includes any applicable changes to the documentation in this code base
• Includes link(s) to any applicable changes to the documentation in the DBT Platform Documentation (can be to a pull request)

Tasks:

• Run the end to end tests for this branch and confirm that they are passing

[WillGibson]

Some questions.

[WillGibson]

Is this todo not address yet on purpose or by omission?

[ksugden]

on purpose as we were not currently handling this so need to do some investigation to decide what we should return in the case of not being able to resolve one of the versions. Will be addressed in a follow up PR as part of the same ticket.

[WillGibson]

I started writing this suggestion, then realised that the two concrete implementations methods have different arguments. So I'm wondering what the benefit of the abstract class is?

Suggested change

	class VersionProvider(ABC):
	pass
	class VersionProvider(ABC):
	@abstractmethod
	def get_latest_version(repo_name: str, tags: bool = False) -> SemanticVersion:
	pass

[WillGibson]

I wonder whether the interface can be the same if GithubVersionProvider. get_latest_version() returns whichever version is highest from the releases or tags?

[ksugden]

We'll address this in one of the next PRs.