Skip to content
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

1.1 Release Planning #768

Closed
priteshbandi opened this issue Aug 25, 2023 · 6 comments
Closed

1.1 Release Planning #768

priteshbandi opened this issue Aug 25, 2023 · 6 comments
Labels
enhancement New feature or request
Milestone

Comments

@priteshbandi
Copy link
Contributor

priteshbandi commented Aug 25, 2023

Using this issue to build consensus on date and user stories/issues to be included in notation-1.1 release.

Proposed Date: Oct 15 Nov 13 2023 (Monday)

Proposed user stories :

  1. Notation to sign and verify arbitrary data #741

PS: This is work in progress, please edit it or add comments to suggest/propose more issues. Created this issue because we already have bunch of issues marked with 1.1 milestone and in my opinion we should have frequent releases with few high priority issues. This way we would be able to release features faster.

cc:/ @iamsamirzon @toddysm @yizha1

@yizha1
Copy link
Contributor

yizha1 commented Aug 31, 2023

Here is the prioritized feature list. For features cannot be scoped in v1.1, they could be planned in v1.2

  1. Sign and verify arbitrary data

  2. Sign container images before pushing to OCI registries

    • need work on the scenarios and make sure whether experimental feature sign OCI layout can meet the requirement
  3. Support OCI 1.1 (Dependency on the release of OCI community)

  4. Improve UX of installation/uninstallation of notation plugin

    • Currently users need to manually download plugin packages for different platforms and extract it to notation plugin folder properly, there is an existing PR for introducing install/uninstall commands to install plugin from a file but need to work on an ultimate experience.
  5. Improve experience of managing trust store and trust policy

    • Improve the output of trust store command
    • support adding root certificates from a URL, so that users don't need to download it firstly
    • Trust policy can only be edited manually, no CLI commands to manage trust policy, which is a broken experience. Need to improve user experience and scripting capability for trust policy
  6. Supports JSON output and allow easy scripting

    • to improve integration in a CICD environment
  7. Improve verbose logs for troubleshooting

    • verbose logs are missing for some commands, and some logs are not helpful.
  8. Simplify the cleanup of testing keys/certs/configs generated by notation cert generate-test

    • to improve user experience for quick-start users

I will add issue links later. I would like to suggest we align the scenario and solution first for each feature, and then we can do the specs and implementation in parallel.

/cc @priteshbandi @iamsamirzon @toddysm @shizhMSFT @FeynmanZhou @sajayantony

@FeynmanZhou
Copy link
Member

Regarding the proposed date from @priteshbandi , I feel it might be a bit tight since the proposed ETA only has two months between the v1.0.0 release.

I think we may need to consider a regular release cycle for Notation. As the Notary Project matures since the v1.0.0 release, keeping four releases a year (once a quarter) sounds more reasonable to the project.

Why propose a regular release cadence?

  • It sets a proper expectation for end users and integrators. I believe it will balance a variety of factors for stakeholders: end users and integrators will get anticipatable and longer support terms for each version.
  • Do a minor/major release includes not only implementation, but also design, spec, test, docs, blogs. The release management overhead for maintainers diminishes allowing the team to spend more time on improving the quality of the software releases and the tooling that drives them.

Patch release can be frequent and based on the security issues or vulnerability fix status.

In conclusion, based on the proposed feature list for v1.1 and the release cadence, I think the ETA is suggested to set at the middle of November 2023.

I am open to both the release scope and release cadence. Let me know if you have any ideas.

@yizha1 yizha1 removed the triage Need to triage label Sep 5, 2023
@yizha1 yizha1 added this to the 1.1.0 milestone Sep 5, 2023
@yizha1
Copy link
Contributor

yizha1 commented Sep 5, 2023

@priteshbandi
Copy link
Contributor Author

priteshbandi commented Sep 5, 2023

IMO we should target for #741 and #777 as MUST have and rest as optional. By optional, I mean if we have them push by agreed upon release date we will add them but if not available wont block release on them.

With above scope change can we target 11/15 instead of 11/30?

@yizha1
Copy link
Contributor

yizha1 commented Sep 7, 2023

As discussed during meeting at 9/4/2023. The code freezing date is 11/15/2023, the release date is 11/22/2023.

@yizha1
Copy link
Contributor

yizha1 commented Sep 19, 2023

Closed as the 1.1 release plan is aligned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

3 participants