root
/
kubevela
mirror of https://github.com/kubevela/kubevela.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity
kubevela/design
History
Kanchan Dhamane bc15e5b359
Feat: Semantic versioning support for Definitions (#6648) 
* feature: Add Semantic versioning to KubeVela Definitions

Fixes https://github.com/kubevela/kubevela/issues/6435
Fixes https://github.com/kubevela/kubevela/issues/6534

Changes:
- Adds an optional "Version" field for all Definition Specs.
- Adds the following new validations to Webhooks for Definitions:
	- Validate the "Version" field follows Semantic versioning.
	- Dis-allow conflicting versioning fields ( Name annotation, Spec.Version)
- Adds the following new validations to Webhooks for Application:
	- Dis-allow the use of both the "publishVersion" & "autoUpdate" annotations.
- Enahnce "multiStageComponentApply" feature to support auto updates.

Boy Scout Changes:
- Fixes Plugin e2e tests broken by the fix for 6534.
- Fixes the dryRun and livediff commands to respect the "-n" namespace flag.
- Fixes the Application ValidationWebhook to respect the "-n" namespace flag.

Co-authored-by: Rahul Kumar <35751394+bugbounce@users.noreply.github.com>
Co-authored-by: Chaitanya Reddy <chaitanyareddy0702@gmail.com>
Co-authored-by: Vibhor Chinda <vibhorchinda@gmail.com>
Co-authored-by: Shivin Gopalani <gopalanishivin@gmail.com>

Signed-off-by: kanchan-dhamane <74534570+kanchan-dhamane@users.noreply.github.com>

* feature: Add KEP to define the proposal

Signed-off-by: kanchan-dhamane <74534570+kanchan-dhamane@users.noreply.github.com>

* fix: Rebase and fix merge conflicts

Signed-off-by: kanchan-dhamane <74534570+kanchan-dhamane@users.noreply.github.com>

* Fix: Adds unit test cases

Signed-off-by: kanchan-dhamane <74534570+kanchan-dhamane@users.noreply.github.com>

---------

Signed-off-by: kanchan-dhamane <74534570+kanchan-dhamane@users.noreply.github.com>
Co-authored-by: bugbounce <35751394+bugbounce@users.noreply.github.com>
 		2025-02-03 11:09:28 +08:00
..
api Chore: remove legacy rollout and scope (#6068) 2023-06-05 10:57:38 +08:00
platform design: add scenarios of ML Platform Building 2021-08-05 10:28:28 +08:00
resources Feat: SDK generating framework (#5431) 2023-02-21 15:54:44 +08:00
vela-cli Feat: add sub-module to Golang SDK (#5655) 2023-03-24 11:28:56 +08:00
vela-core Feat: Semantic versioning support for Definitions (#6648) 2025-02-03 11:09:28 +08:00
README.md Docs: add KEPs introduction to the main repo (#5099) 2022-11-21 15:19:31 +08:00
TEMPLATE.md Docs: add KEPs introduction to the main repo (#5099) 2022-11-21 15:19:31 +08:00

README.md

KubeVela Enhancement Proposals (KEPs)

This directory is a place to propose and discuss new ideas of KubeVela concepts, designs, architectures and techniques.

When do we need KEPs

When major changes are intended to be made to KubeVela project, we need KEPs. Major changes includes:

  • New project-level features that add modules to the architecture, like new Controller or APIServer.
  • Break changes to the core concepts of KubeVela, such as Application, Workflow, Component, etc.
  • Techniques or domains that lots of related enhancements need to be added to KubeVela, like multi-cluster, observability, etc.

Changes to the internal mechanism of core KubeVela are recommended to add proposals as well, including:

  • Application behaviours and related policies: State-keep, garbage-collect, resource dispatch, etc.
  • API changes of auxiliary resources in KubeVela, such as ApplicationRevision, ResourceTracker.
  • New concepts and layers in KubeVela APIServer on VelaUX, such as Project, Target, etc.

Minor changes and enhancements do not necessarily need to be included, but instead recommended to be tracked by issues, such as

  • New addons.
  • New Component/Trait/WorkflowStep definitions.
  • New additional function APIs in APIServer.
  • Bug detection and fixes.
  • Auxiliary commands in CLI.

Areas

There are several directories contained. Each directory contains the KEPs in specific area.

  • /vela-core: The proposals of features and changes to the core KubeVela, including Application APIs, internal mechanisms, auxiliary policies, etc.
  • /vela-cli: The proposals of features to the KubeVela CLI, such as vela top, vela def.
  • /api: The proposals of the interfaces KubeVela exposes to users, such as command line args for the core controller.
  • /platform: The proposals of integrating features in various related areas outside KubeVela, such as edge computing, artificial intelligence.
  • /resources: The related images embedded in the design documentations.

Writing a new Proposal

The aim of a proposal is to communicate designs with others and give KubeVela users some basic ideas of how features and evolved and developed.

To reach that, there are several things seed to be included in a proposal.

  1. The background of the feature or change, which explains why we need it.
  2. The goals and non-goals for the proposal.
  3. The potential technical solutions for the proposal and comparisons between various solutions. (Single solution is also acceptable.)
  4. How we should move on for the proposal. The estimated milestones or timelines for the feature development.

Submitting a new proposal

We recommend to use the template to start a new proposal. After finishing the proposal in the proper directory, raise a pull request to add the proposal to the main repo. If there are any issues related to the proposal, you can also add links to the issues in the pull request.