Once Skooner version v1.0.0 is released, subsequent releases will follow Semantic Versioning. Until then, breaking changes may occur without an uptick to the Major version.
Versions will use the v<semantic version> tag pattern.
Method:
- Release current content in Stable branch as a Minor/Patch release
- Replace Stable branch content with everything from Main branch
- Release updated Stable branch as a Major release
Method: Release Stable branch as a Minor/Patch release
- To support agile feature additions at a regular pace, users of Skooner can expect Stable updates on each Major version before needing to review any breaking changes. Users can simply subscribe to a particular Major version and pull the latest changes for that version without worry.
- If users want to be on the cutting edge, they have the option of subscribing to the latest changes on the Main branch.
- Helpful when needing to perform security patches for previous Major releases, fewer Major releases means less work.
- Contributor: Fork from Main
- Contributor: Develop in your Fork
- Contributor: Prep PR by cleaning up your work and merging updates from the upstream repo
- Contributor: Submit PR against Main
- Maintainer: Perform a code review and identify potential breaking changes
- If there are breaking changes, the PR might not be merged until the following Major Release
- However, if backwards compatibility can be added to the change, attempt to remediate the breaking change before completing the merge to Main
- This project typically doesn't have breaking changes, so ideally this is rare
- Maintainer: If the change is not a breaking change, merge to Stable
- Additional steps may be added in the future
In general, if logic exists that interfaces with anything outside of Skooner (including user interfaces), removing that logic or changing the contract is likely considered a breaking change. Adding content/features to a user interface is additive and not a breaking change, unless it results in a major negative performance impact.
The rest of this section will go into more detailed examples of breaking changes.
Reasons this might happen:
- Adding a feature that only works on newer K8s clusters and not having a feature switch that would allow for the new feature to go dark on older cluster versions, maintaining the functionality that was present before the feature add.
- Removing any logic that is needed to support a particular K8s cluster version
HPA for example:
- If HPA support is removed
- Logic is added to scrape the new HPA CRD fields provided in K8s 1.18 and isn't able to continue supporting the limited information from 1.17.
Browser support is an important interface because companies often leverage a single browser for all needs and sometimes they get locked into old versions for a variety of reasons. The following are examples of breaking changes:
- Removing support for a browser type (Mozilla, Chrome, etc)
- Removing support for a browser version
- Adding a feature that won't work on an older browser, such as the deprecations mentioned above
Deprecation of a previously supported version of OpenId Connect
Deprecation of a previously supported version of metrics-server
Changes in the minimum resource requirements for the deployment, due to a feature change. This can be hard to identify, but ideally is considered in obvious cases.
A new feature might be more CPU intensive or require caching that increases memory requirements. Without this new minimum, Skooner might crash. Consider the following:
- How might the requested change impact the performance of pulling or presenting a list of N items on large and active clusters?
- Pulling a large dataset (even for a few items), depending on the auto-refresh frequency and use frequency, could cause congestion, even on a small cluster
- Any added caching might increase the minimum memory consumption