Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADR0003: where to develop TUF 1.0.0 #1220

Merged
merged 3 commits into from
Nov 27, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions docs/adr/0003-where-to-develop-TUF-1-0-0.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Develop TUF 1.0.0 in a subdirectory of the current TUF implementation

* Status: accepted
* Date: 2020-11-23

Technical Story: https://github.com/theupdateframework/tuf/issues/1126

## Context and Problem Statement

The plan is to implement a refactored TUF (1.0.0) alongside the current
code base, in order to not disrupt existing usage and keep providing
a Python 2.7 client.

We need to decide on the best place to do this development.

## Decision Drivers

* Developing the new code piecemeal
* Continuing to make releases in the interim
* Avoiding maintenance overhead

## Considered Options

Develop TUF 1.0.0:

* In its own repository
* In a separate development branch of the current TUF implementation
* In the default branch, archiving the current implementation
* In a subdirectory of the current TUF implementation

## Decision Outcome

Chosen option: "Develop TUF 1.0.0 in a subdirectory of the current TUF
implementation", because we want to add the new TUF code gradually
while keep maintaining the current implementation given limited
maintenance resources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit: Should we somehow underline that this option seems to have the least maintenance overhead compared to option 1 and 2, while allowing us to continue making releases with the old code unlike option 3?


Once development of the new version is complete, we will transition
from TUF 1.0.0 in a subdirectory to stand-alone TUF 1.0.0 by the following
procedure:

* flesh out tuf/api/*
* implement tuf/client/new-updater.py
* implement tuf/repository/*
* \<iterate\>
* git mv tuf/client/new-updater.py tuf/client/updater.py
* git rm tuf/\*.py
* tag 1.0.0

## Pros and Cons of the Options

Developing TUF 1.0.0 in a subdirectory of the current TUF
implementation seems to have the least maintenance overhead compared to
option 1 and 2, while allowing us to continue making releases with the
old code unlike option 3.

### Negative Consequences

* In progress development in the default branch causes messiness
in plain sight.

## Links

* [Discussion of Python version support in TUF 1.0.0](https://github.com/theupdateframework/tuf/issues/1125)
* [Discussion of deprecation policy for the pre-1.0, Python 2.7 supporting, code](https://github.com/theupdateframework/tuf/issues/1127)
1 change: 1 addition & 0 deletions docs/adr/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ This log lists the architectural decisions for tuf.
- [ADR-0000](0000-use-markdown-architectural-decision-records.md) - Use Markdown Architectural Decision Records
- [ADR-0001](0001-python-version-3-6-plus.md) - Default to Python 3.6 or newer for new development
- [ADR-0002](0002-pre-1-0-deprecation-strategy.md) - Deprecation strategy
- [ADR-0003](0003-where-to-develop-TUF-1-0-0.md) - Develop TUF 1.0.0 in a subdirectory of the current TUF implementation

<!-- adrlogstop -->

Expand Down