Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 298
Decide on deprecation strategy #1127
Copy link
Copy link
Closed
Labels
decision recordOutcome of this discussion should be tracked in a decision recordOutcome of this discussion should be tracked in a decision recorddiscussionDiscussions related to the design, implementation and operation of the projectDiscussions related to the design, implementation and operation of the projectdocumentationDocumentation of the project as well as procedural documentationDocumentation of the project as well as procedural documentation
Description
Metadata
Metadata
Assignees
Labels
decision recordOutcome of this discussion should be tracked in a decision recordOutcome of this discussion should be tracked in a decision recorddiscussionDiscussions related to the design, implementation and operation of the projectDiscussions related to the design, implementation and operation of the projectdocumentationDocumentation of the project as well as procedural documentationDocumentation of the project as well as procedural documentation
The current plan is to develop the new TUF alongside the old TUF (see #1126).
How long after the refactor is complete will we continue to support the old code base? What does support look like? Bug fixes? Security fixes? We need a roadmap there. The main reason to keep the old code base around is to have a client that supports Python 2.7 (see #1125). Not sure if this is a good reason for very much longer.
Independently of the refactor, we might generally want to think of a deprecation strategy for the future. E.g. do we want to display deprecation warnings for n releases before we drop interface functions? This probably only makes sense if we follow a stricter release schedule than we do now.