TAP 12: 1.0 release schedule

[vladimir-v-diaz]

This pull request adds a draft of TAP 12 (1.0 release schedule). It covers the release schedule and anticipated features for the 1.0 release of the reference implementation.

Note: We need to settle on an EOL for the 1.0 release, preferably with community input.

Signed-off-by: Vladimir Diaz [email protected]

[trishankatdatadog]

@JustinCappos Why was this closed? It's super-critical to those using TUF in production to know pre-release and release schedules, and where backwards-incompatible TAPs are being implemented. Thanks.

[JustinCappos]

We'll do this, but I don't think the right way is with TAPs. If you feel strongly we should use the TAP process for this, I suppose we can discuss, but I'd rather announce and do this separately.

…

On Tue, Nov 20, 2018 at 4:28 PM Trishank K Kuppusamy < ***@***.***> wrote: @JustinCappos <https://github.com/JustinCappos> Why was this closed? It's super-critical to those using TUF in production to know pre-release and release schedules, and where backwards-incompatible TAPs are being implemented. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#103 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD1DAEpN-erknD77Fo8Gp-wGVrsr3ks5uxHPpgaJpZM4UsSo-> .

[trishankatdatadog]

That's fine, but we need to formalize the process somewhere, and I can't think of anything better than TAPs right now for this. It seems like a good idea to hold commitments somewhere. IIRC, Python uses PEPs to plan release schedules and backwards-incompatibilities, too.

@SantiagoTorres What are your thoughts?

[awwad]

TAPs are intended, I think, more for the TUF specification than for the reference implementation, and release schedules relate to the reference implementation.

Is there an issue with, say, publishing release candidates that indicate when they'll be succeeded by an official release (and of course indicating in the release notes where backward compatibility is threatened)? That seems more lightweight but also like it would serve your needs? I'd imagine that you wouldn't necessarily want to have to wait for a scheduled release if something important was missing. We're also a pretty lightweight operation, so I don't know that we need something so rigid as TAPs for releases.

[SantiagoTorres]

Well this is part of what irks me about TAPs in a sense. Are they for the TUF project or are they related to just the specifciation? Quoting TAP 1:

A TAP is a design document providing information to the TUF community, or describing a new feature for TUF or its processes or environment.

I don't really see why it couldn't be a process TAP to describe a release schedule. I also don't really know where else could it be discussed that's formal enough. I'd rather avoid having a release schedule put in a github ticket or an email thread.

[trishankatdatadog]

@awwad It's not enough to just warn in a changelog. People might be installing TUF from a CI/CD pipeline, and not expect things to break.

@vladimir-v-diaz and I had an informal agreement that as long as you constrained pip to the MAJOR.MINOR.* line (e.g., 0.11.*), you should not see breaking changes, but this needs to be formalized.

[trishankatdatadog]

@SantiagoTorres 💯

[SantiagoTorres]

@vladimir-v-diaz and I had an informal agreement that as long as you constrained pip to the MAJOR.MINOR.* line (e.g., 0.11.*), you should not see breaking changes, but this needs to be formalized.

This sounds very reminiscent of semver. I assume formalizing it as "we're adopting semver with these specifics" would suffice?

[trishankatdatadog]

@SantiagoTorres Yes, and we need to formalize this somewhere