The following issue is a placeholder for discussing the migration strategy of deprecating the current go-tuf code base in favor of https://github.com/rdimitrov/go-tuf-metadata.

Reason
The reasoning behind this is the discussions we've been having in the go-tuf community for the past 1+ years regarding the overall maintainability and usability of the current implementation. There are several less-than-optimal design decisions in go-tuf which often cause a lot of unnecessary implications both for the maintainers of the project but also for the actual users. Adding a feature or a simple bug fix (i.e. #272) sometimes ends up being surprisingly difficult to implement and review, and unfortunately, that makes it much harder to attract new contributions too.

Python-tuf was in the same situation and its community decided to do the same thing successfully redesigning its codebase approx. 2 years ago. The go-tuf community got inspired by this and evaluated that it would be worth to try and apply the same design principles used in python-tuf to create a new Go-based TUF implementation.

The result of this effort is the https://github.com/rdimitrov/go-tuf-metadata project.

Another example of this approach was developed in parallel - https://github.com/theupdateframework/tuf-js, which is a javascript-based implementation of TUF again based on the python-tuf design.

Goal
The end goal is to deprecate the current go-tuf codebase and replace it with the one from https://github.com/rdimitrov/go-tuf-metadata, so we continue to use the same repository location. The following are some of the things we need to complete in not order to accomplish that:

• Decide on how to begin announcing this intention. Maybe have N releases (2 should be enough but maybe more?) where we say that users should expect this change in the future? Perhaps, once we have a rough estimation we can put a date on which the new release will happen?
• For how long should we support the old version after the migration is completed? Should it be in a separate branch?
• The go-tuf project has several things in it. On one side there's the go-tuf package, then there are client and repository-side CLI tools but also other miscellaneous things. We should assess what needs to be abstracted/kept away from the current code base (like Move the encrypted package away from go-tuf #476)
• rdimitrov/go-tuf-metadata should have proper test coverage and documentation
• Should we provide, and thus implement the CLI tools too using the new metadata implementation? If so, where should their code reside? Same or a separate repository?
• Prepare proof-of-concept implementations for some existing clients of go-tuf using https://github.com/rdimitrov/go-tuf-metadata. This should help justify and verify such API transition. There are already a few things like that for sigstore's cosign and sigstore library.

These are just some of the action items, but of course, more will be added in the process of this discussion.