Changelog since 1.8 🚨 Breaking or Notable Knative will now warn (but not error) when creating or updating a PodSpec where containers have additional privilege due to unset SecurityContext values. Explicitly setting these values to any setting, including high-privilege ones, will disable this warning.These fields are:runAsNonRoot (empty means false) allowPrivilegeEscalation (empty means true) seccompProfile.type (empty string means Unconfined) capabilities.drop (default maintains privileges, use ALL to drop unneeded linux capabilities) (#13399, @evankanderson)

**Authors: Evan Anderson (VMware), Paul Schweigert (IBM) Date: 2022-07-12 A new version of Knative is now available across multiple components. Follow the instructions in Installing Knative to install the components you require. This release brings a number of smaller improvements to the core Knative Serving and eventing components, and several improvements to specific plugins, in particular net-kourier, net-gateway-api, and eventing-rabbitmq.

Changelog since 1.1 🚨 Breaking or Notable 💫 New Features & Changes 🐞 Bug Fixes Uncategorized Dependencies Added Changed

Term Definition Base Template Default templates provided with func binaries Top-Level Guidelines Only 2 base templates per runtime (cloudevents + http) All base templates should offer the same user experience, regardless of runtime.

The Knative website has a basic, top-level navigation that looks like this: nav: - Home: - Getting started: - Installing: - Serving: - Eventing: - Code samples: - Reference:

See example here: Broker Lifecycle Conformance From: [ ] Link to subheading in Spec From the Spec: [ ] Copy and paste all relevant sections of the spec

Background Over the course of the last few months, the DUX WG has conducted ~30 user interviews with a range of different users. I have taken learnings from these interviews and from months of thinking about Knative from the lense of a Product Manager operating within the community to create this document. Why now? As Knative introduces more developer-focused functionality, like func, it's important to define what user's needs we're addressing and why. As Knative matures and seeks to onboard new vendors and integrators, it's important to define a persona which represents them to ensure we'r considering them as we make decisions. Knative has outlasted some of its early competition to be the standard Serverless layer on top of Kubernetes; to beat out the well-funded, well-connected recent entrants to the market we need focus around who we are serving. Outline

Schedule [Writing] Product vs. Project (Released July 15) [Writing] Knative User Personas for Docs (TBD) [Writing] Knative Stakeholder Personas (TBD)

Background In the past few months, Knative has been chasing “1.0” and “Conformance,” in many conversations these terms are used as synonyms, or at the very least are said in the same breath. It seems many folks are holding context for these efforts (in their brains), and this brief document is a reflection of “the world as we see it,” (we being Naina S. and Omer B.) as well as what ought to be done to get us to where we need to go. :::success First off, a thank you to the TOC, Steering, and TM Committee for their work aligning the disparate and varying interests in relation to 1.0 and Conformance (crystalized in this document). More specifically, a big thank you to Evan Anderson who has done some excellent work organizing the results of these efforts into a cohesive spreadsheet. ::: Defining Conformance, Defining an Audience I want to take a quick second to loosely define Conformance as it relates to Knative. Conformance is the process of validating that a given environment implements the Knative Serving or Eventing interfaces. That is to say, a Conformant Platform would be one in which some code which is built to align with the Knative Specification (spec, for short) can run without issues. In other words, this means creating a series of tests that will ensure that Platform runs as per the provided Knative specification with varying levels of Conformance. MUST, SHOULD, SHOULD NOT, etc. e.g. "the platform MUST allow you to spin up a Knative Service (KSVC) with a standard manifest and SHOULD give you some abilities on top of that KSVC".

This document will be part of a series I'm calling the "Knative Product Series," which will include musings/presentations/discussions viewing Knative from a product lense as well as thoughts on what Knative can teach us about the future of Open Source development. A lightweight schedule can be found here: The Knative Product Series Background ==Over the course of the last few months, there has been an unspoken shift in the way our community is thinking about Knative.== This change is a simple shift in mental model: a shift from Knative the project to Knative the product. One could even chart this change along recent community actions: beginning with the acceptance of the UX WG and cresting with the conversations being had around the introduction of func. The question we, as a community, ought to be asking ourselves is simple: who is the audience of our work? ==Are we building a project for vendors or a product for end users?==

title: "v0.24 release" linkTitle: "v0.24 release" Author: "Omer Bensaadon" Author handle: https://github.com/omerbensaadon date: 2021-06-29 description: "Knative v0.24 release announcement" type: "blog" image: knative-eventing.png Announcing Knative v0.24 Release A new version of Knative is now available across multiple components.

Write Release Notes, save as a HackMD, tag with Release Notes Look over PRs to see if any are ready for a /lgtm Create a release branch for the next release: https://knative.dev/help/maintainer/docs-release-process/#create-branch-from-updated-main Edit build.sh on main to reflect current versions, PR the changes Consistency Check the preview for edited build.sh generate by Netlify Merge PR See this PR for an example: https://github.com/knative/docs/pull/3959/files

Stakeholder Personas Nelly the New Vendor Iggy the Integrator Eddie the Existing Vendor Carmen the Contributor

This week, the Knative Documentation + User Experience Working Group has launched a completely redesigned Knative.dev for v0.24 The release of the new Material for MkDocs-based site is the result of over 30 user interviews + tests, weeks of project management and development, and represents the work of 20+ contributors working on a tight schedule. This is only the beginning! We've got lots of other changes in store so check back soon. Major Changes A new homepage Getting Started Experience

Architecture There are two main workflows for the func tool: Initiation This is the workflow for the start of a project: |#lightgreen|Plugin| |#lightblue|Func common| start :func create <path> $LANGUAGE;

For a task list, please see Eventing to 1.0 project board. Work Week 20, 21 [ ] Finish Broker Conformance tests. blocked on https://github.com/knative/specs/pull/24 [ ] Finish Channel Conformance tests.

Breaking Changes Default replication factor is 3 (1 previously) (#375, @sheetalsingala) Actions Required (pre-upgrade) Run kubectl delete configmap -n knative-eventing kafka-broker-brokers-triggers :gift: New Features

Eventing ✅ knative/eventing GO Waiting on https://github.com/knative/eventing/pull/4492 Created - https://github.com/knative/eventing/tree/release-0.19 manually triggered eventing auto-release https://prow.knative.dev/view/gs/knative-prow/logs/ci-knative-eventing-auto-release/1326238389158023168 Released - https://github.com/knative/eventing/releases/tag/v0.19.0

Documentation :gift: New Features Now setting the channel spec delivery field defaults every subscription to that particular delivery spec (#4652, @slinkydeveloper) :bug: Bug Fixes :bug: Allow scaling the in-memory Channel dispatcher without disabling high availability. (#4675, @antoineco)