Skip to content

Prepare v0.17.0 release #1284

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Feb 25, 2021
Merged

Prepare v0.17.0 release #1284

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
32 changes: 32 additions & 0 deletions docs/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,37 @@
# Changelog

## v0.17.0
**NOTE**: this will be the final release of tuf that supports Python 2.7.
This is because Python 2.7 was marked [end-of-life](
https://www.python.org/dev/peps/pep-0373/) in January of 2020, and
since then several of tuf's direct and transient dependencies have stopped
supporting Python 2.7.
Copy link
Member

Choose a reason for hiding this comment

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

Should we add max version constraints to requirements.txt and setup.py? Without constraints people won't be able to install TUF 0.17.0 dependencies on Python 2.7 as soon as any of the dependencies releases a newer version without Python 2.7 support.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good point. This might be a good justification for a release branch too, as dependencies drop Python 2.7 support we can add the max version constraint in the release branch for people who continue to use Python 2.7.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that would mean that we would have to list our transitive dependencies in requirements.txt

Copy link
Member

Choose a reason for hiding this comment

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

I think that would mean that we would have to list our transitive dependencies in requirements.txt

Agreed. requirements.txt and requirements-pinned would list the same dependencies but with different constraint markers.

# in requirements.txt

dependency1 < X.Y.Z    # no py2 above X.Y.Z
dependency2            # hasn't dropped py2 yet

# in requirements-pinned.txt 
dependency1 < X.Y.Z      # ignored by dependabot 
dependency2 == Y.V.W.    # bump with dependabot until py2, then constrain here and in requirements.txt

This definitely calls for a py2 branch

Copy link
Collaborator

Choose a reason for hiding this comment

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

What are the advantages of having a release branch compared to what we do now?

Copy link
Member Author

Choose a reason for hiding this comment

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

Once we make the release we don't want to add any new features for Python 2.7, only fixes. If we do need to add fixes for Python2.7 we can create a branch at the point we tagged the release and add fixes there which are likely to be changes that don't exist in the develop branch, or changes implemented differently to similar changes in the develop branch.

We would usually release fixes and features together in a new release, the release branch enables us to release fixes without features and without having to hold features from landing in the develop branch.

Copy link
Member

Choose a reason for hiding this comment

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

I guess these decisions are mostly up to whoever cares about and maintains the 0.17 (or python2) branch.

Or is there a suggestion here that we should do something now, before this release?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess these decisions are mostly up to whoever cares about and maintains the 0.17 (or python2) branch.

Or is there a suggestion here that we should do something now, before this release?

I think @lukpueh's concern is that if we don't do something before the release, then a pip install tuf with python 2 can easily be broken when one of our dependencies (direct or transitive) updates and drops Python2 support.

I think the only way to resolve this is to list version constraints in our setup.py, because the install_requires lines in the setup.py are what pip uses to install dependencies [1].

Copy link
Member

Choose a reason for hiding this comment

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

That was indeed my concern, @joshuagl. And, yes, we'd need to do in setup.py what I sketched out for requirements.txt above. We can even get rid of requirements.txt.

I'd still keep requirements-pinned.txt though, to track any future py2 drops in direct and transitive dependencies, using Dependabot and automatic builds, so that we can little by little constrain all direct and transitive dependencies in setup.py in future patch releases on a py2 release branch.

Alternatively, we can add all direct and transitive dependencies to setup.py and constrain them right away, and really make this the last Py2 release period. This would mean no more py2 work for us, which seems reasonable, but also doesn't allow py2 tuf users install any newer dependency updates that might still support py2.


### Added
* Added Architectural Decisions Records (ADRs) for:
* where to develop python-tuf 1.0 (#1220)
* to justify the extent of OOP in the metadata model (#1229)
* to decide on a Python code style guide (#1232)

### Changed
* Switch to GitHub Actions for CI (#1242, #1283, #1252)
* Switch to only running bandit on Python versions greater than 3.5 (#1234)
* Bump dependencies: requests (#1245), chardet (#1239), urllib3 (#1268),
cffi (#1280), securesystemslib (#1285), cryptography (#1282, #1286).
**NOTE**: the latest version of cryptography is no longer used on
Python 2, as that is not supported.
* Moved from dependabot-preview to GitHub native Dependabot (#1258)
* Configure dependabot to ignore idna, as it breaks Python 2.7 builds (#1259)
* Install securesystemslib in tox in non-editable mode (#1228)
* Change the editable venv installation order (#1271)

### Fixed
* Updated expiration check in Updater to better match the specification (#1235)
* Ensure tempfile's are closed in Updater (#1226)

### Removed
* Dropped support for Python 3.5 (#1238)

## v0.16.0
### Added
* Begin to document architectural and project-wide decisions as Architectural
Expand Down
2 changes: 1 addition & 1 deletion setup.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,7 @@

setup(
name = 'tuf',
version = '0.16.0', # If updating version, also update it in tuf/__init__.py
version = '0.17.0', # If updating version, also update it in tuf/__init__.py
description = 'A secure updater framework for Python',
long_description = long_description,
long_description_content_type='text/markdown',
Expand Down
2 changes: 1 addition & 1 deletion tuf/__init__.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
# setup.py has it hard-coded separately.
# Currently, when the version is changed, it must be set in both locations.
# TODO: Single-source the version number.
__version__ = "0.16.0"
__version__ = "0.17.0"

# This reference implementation produces metadata intended to conform to
# version 1.0.0 of the TUF specification, and is expected to consume metadata
Expand Down