-
Notifications
You must be signed in to change notification settings - Fork 19
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
TAP 12: 1.0 release schedule #103
TAP 12: 1.0 release schedule #103
Conversation
Signed-off-by: Vladimir Diaz <vladimir.v.diaz@gmail.com>
Signed-off-by: Vladimir Diaz <vladimir.v.diaz@gmail.com>
Signed-off-by: Sebastien Awwad <sebastien.awwad@gmail.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. |
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->
.
|
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? |
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. |
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:
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. |
@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. |
This sounds very reminiscent of semver. I assume formalizing it as "we're adopting semver with these specifics" would suffice? |
@SantiagoTorres Yes, and we need to formalize this somewhere |
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 vladimir.v.diaz@gmail.com