ADR0003: where to develop TUF 1.0.0

[sechkova]

Fixes#1126

Description of the changes being introduced by the pull request:

Document the outcome of #1126: develop TUF 1.0.0 in a subdirectory of the current TUF implementation.

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[lukpueh]

Thanks for the PR, @sechkova. I have one minor nit (see inline) but other than that it looks solid.

[lukpueh]

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?

[lukpueh]

Not sure if this should be part of AD0003, or should have been part of ADR0002, or neither, but we also need to decide how to transition from TUF 1.0.0 in a subdirectory to stand-alone TUF 1.0.0. Im fine if we cross that bridge when we get there (e.g. with the help of git filter-branch-sorcery). cc @joshuagl

[trishankatdatadog]

I'm ok with developing in a separate dir in the current default branch, as long as we're not committed to legacy code. Should we clarify this in the ADR, if we all agree?

[joshuagl]

Not sure if this should be part of AD0003, or should have been part of ADR0002, or neither, but we also need to decide how to transition from TUF 1.0.0 in a subdirectory to stand-alone TUF 1.0.0. Im fine if we cross that bridge when we get there (e.g. with the help of git filter-branch-sorcery). cc @joshuagl

The way I've been imaginging it, filter-branch wizardry would not be required. In my mind we'd have something like:

• 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

[joshuagl]

Thanks for writing this up @sechkova !

[joshuagl]

I'm ok with developing in a separate dir in the current default branch, as long as we're not committed to legacy code. Should we clarify this in the ADR, if we all agree?

I believe we all agree. I think it's implicit in ADR 0002 that we are not committed to legacy code?

[joshuagl]

Per #1203 (review) and the discussion in #1127 we still need to document:

a deprecation/API stability strategy for releases after the refactor

Perhaps we can ensure we are not committed to maintaining legacy code with that document?

[lukpueh]

The way I've been imaginging it, filter-branch wizardry would not be required. In my mind we'd have something like:

• flesh out tuf/api/*
• implement tuf/client/new-updater.py
• implement tuf/repository/*
• 💻
• git mv tuf/client/new-updater.py tuf/client/updater.py
• git rm tuf/*.py
• tag 1.0.0

Sounds like a good plan and a good fit for an addendum to ADR0003?

[joshuagl]

The way I've been imaginging it, filter-branch wizardry would not be required. In my mind we'd have something like:

• flesh out tuf/api/*
• implement tuf/client/new-updater.py
• implement tuf/repository/*
• 💻
• git mv tuf/client/new-updater.py tuf/client/updater.py
• git rm tuf/*.py
• tag 1.0.0

Sounds like a good plan and a good fit for an addendum to ADR0003?

Agreed. Would you mind outlining the above in ADR0003 @sechkova ?

[sechkova]

Updated with your suggestions.

[lukpueh]

Updated with your suggestions.

Thanks! Could you please also resolve the conflict in docs/adr/index.md?

[sechkova]

Updated with your suggestions.

Thanks! Could you please also resolve the conflict in docs/adr/index.md?

oops .. I forgot .. here it is

[lukpueh]

picobello!