Status of 1.0 release of spec?

[nealmcb]

I see that the specification/README.rst now no longer calls the spec a draft, but the specification/tuf-spec.md itself (dated June 2018) still calls itself a draft.

• What is the status of the spec?
• Will there be a git tag when it is final?
• How does the version number relate to the tuf implementation versions and tuf/ROADMAP.md?

[awwad]

Spec Status:

The spec will continue to evolve, generally through TAPs (TUF Augmentation Proposals), meaning that future versions are expected.

We'll issue a git tag when each version of the spec is finalized. I'll get back to you about the status of 1.0 in particular in the coming weeks.

As it predates this policy, version 0.9 of the spec -- which is finalized -- is available in all recent versions of the repository.

Spec Version in the Reference Implementation

The ways that specification versions are related to TUF implementation versions:

• Metadata includes a specification version indicating the version of the spec to which it conforms.
• Releases of the reference implementation will make note of changes to the specification version with which they are intended to conform.

Do you think it would be helpful to additionally note conformance to a particular specification version in a comment in the code alongside TUF version, where it appears (e.g. in setup.py)?

[JustinCappos]

As for the spec itself, we're planning to wrap appropriate accepted TAPs into the spec and then bump the version number. We're figuring out the cleanest way to do this now. Justin

…

On Wed, Feb 27, 2019 at 12:24 PM Sebastien Awwad ***@***.***> wrote: Spec Status: The spec will continue to evolve, generally through TAPs <https://github.com/theupdateframework/taps> (TUF Augmentation Proposals), meaning that future versions are expected. We'll issue a git tag when each version of the spec is finalized. I'll get back to you about the status of 1.0 in particular in the coming weeks. As it predates this policy, version 0.9 of the spec -- which is finalized -- is available in all recent versions of the repository. Spec Version in the Reference Implementation The ways that specification versions are related to TUF implementation versions: - Metadata includes <https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#4-document-formats> a specification version indicating the version of the spec to which it conforms. - Releases of the reference implementation <https://github.com/theupdateframework/tuf/releases> will make note of changes to the specification version with which they are intended to conform. Do you think it would be helpful to additionally note conformance to a particular specification version in a comment in the code alongside TUF version, where it appears (e.g. in setup.py <https://github.com/theupdateframework/tuf/blob/e97b0b091d9851baa3b7c5d31d758f0af20069d3/setup.py#L84> )? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XDyyhG9oFliq2GEoKVlaFGaniFKwWks5vRr9XgaJpZM4bCBDr> .

[nealmcb]

Ahh - for convenience, here's a link to version 0.9 of the spec, from 2015-05-14: specification/tuf-spec.0.9.txt. I hadn't noticed that there were two versions of the spec next to each other in the repo.
The "1.0 (Draft)" version text has been used to describe the new draft since it first appeared in github on 11 October 2017, it seems.

I'm not sure how helpful a comment in setup.py would be, and there's always risk of such comments getting out-of-date.

Offhand, I wonder if it would be appropriate for at least the major version number of the reference implementation to match the spec version number.

Does the implementation mean to use semantic versioning? Does the spec use Semantic Versioning (semver)? Right now, I see no reference to the term. Both the tests and code use 'spec_version': '1.0' (with no third "fix" version number), though the code says it is assumed that "spec_version" is in (major.minor.fix) format

[awwad]

I'm using this https://www.python.org/dev/peps/pep-0440/#public-version-identifiers for the reference implementation. It's quite close to semantic versioning.

My gut feeling is that if we try to match major version numbers for the spec with major version numbers for the reference implementation, it'll be muddying the semantics of the version numbers (for one, the other, or both). I don't have a particularly strong opinion about that, though.

[nealmcb]

I wouldn't be surprised if you're right about the risks of forcing matches between the spec/implementation version numbers.

In that case I think there does need to be some clear, robust way to clarify what spec versions are supported by an implementation. Text in the README.md (and also in the package long_description, which is automated to match the README.md now) might do so better than a comment in setup.py.

[JustinCappos]

That's a great way to handle this. We'll add this moving forward. [@marina Moore <mnm678@gmail.com>, who may also be interested in this discussion.]

…

On Thu, Feb 28, 2019 at 1:59 PM Neal McBurnett ***@***.***> wrote: I wouldn't be surprised if you're right about the risks of forcing matches between the spec/implementation version numbers. In that case I think there does need to be some clear, robust way to clarify what spec versions are supported by an implementation. Text in the README.md (and also in the package long_description, which is automated to match the README.md now) might do so better than a comment in setup.py. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD2eQ8FB4VmRGSswXWzSEJ5L3gk4zks5vSCcjgaJpZM4bCBDr> .

[lukpueh]

Heads-up:

#51 introduced semantic versioning for the specification (adopted in the reference implementation in theupdateframework/python-tuf#914).

The current stable version of the specification has been tagged as v1.0.0. Future updates to the specification will adhere to the release policy outlined in the Versioning section of the README (introduced by #87).

It looks like we can close here.