SLSA spec v1.0 - Githubissues

MarkLodato commented 2 years ago

Tracking issue for the SLSA spec v1.0 release.

To view the latest draft: https://slsa.dev/spec/v1.0
To view all pending v1.0 issues, grouped and prioritized by objective, see Specification v1.0 project.
To read the original v1.0 design doc, see SLSA v1.0 Proposal.

Timeline:

[x] Draft: Still in development, with some things unfinished. Visible at URL above but not linked from the main site, with a warning banner saying that it is an unpublished draft version. PRs can be approved by a single reviewer to speed development. Does not yet represent broad consensus. During this phase we will address or defer all issues in the v1.0 milestone (except for process ones like this one).
[x] 2023-02-24: Release Candidate 1: Ready for broad review by the community. Linked from the main site but clearly marked as a release candidate. The "v1.0-rc1" URL will remain static, while further development happens on the draft "v1.0" URL (which retains the banner). Announcement: https://slsa.dev/blog/2023/02/slsa-v1-rc
[x] 2023-03-24: End of RC1 comment period.
[x] 2023-03-31: Deadline to get in changes for v1.0. After this, we will freeze v1.0 to only minor fixes, no changes in meaning or significant content additions.
[x] 2023-04-03: Release Candidate 2 announced. This starts the mandatory two-week comment period as a "candidate for approved specification" as per our governance.
[x] 2023-04-19: v1.0 marked "Approved" and announced, updated as the default version on the site.

Notes:

Previously we used a milestone prior to adopting the project to track v1.0.
Previously we used the maybe-1.0 tag to track untriaged issues. No such issues exist any more, so we've deleted the tag.
SLSA spec backlog is a milestone for any issues we decided to defer to a future v1.1 version or later.

MarkLodato commented 1 year ago

Proposed schedule for v1.0, (hopefully!) in line with what we discussed in the Specification SIG:

Any objections or suggested changes?

MarkLodato commented 1 year ago

I propose the following guidelines for changes:

By Fri, March 31: Get in all major changes before we cut RC1. Examples: schema changes, requirements changes, new pages, major layout changes
Following two weeks (until final release): "quiet period" defer any non-urgent changes that could hamper a reader's ability to review
- OK: trivial changes such as typo fixes or website changes
- OK: pages outside the versioned directory (e.g. "How to SLSA")
- OK: adding a What's New page (#592), which we likely won't finish by Friday
- OK: high priority changes (better now than waiting for next release)
- OK: minor clarity changes that are limited in scope and unlikely to be controversial
- Discouraged: shuffling around content
- Discouraged: significant changes in content that require community consensus
After the release: go back to normal
- Significant changes require several days to review, multiple approvals, etc.

Thoughts?

Ajsiqosnsizidnswikw commented 1 year ago

Ajjajajs

slsa-framework / slsa