Releases

We follow semantic versioning, and the release notes are available on the GitHub releases page.

Release Cycle

Sodacore doesn't have a fixed release cycle, but we aim to keep the framework up to date as often as possible.

• Patch releases are done as and when needed, and will cover bug fixes, and security patches.
• Minor releases are done when we have new features, or improvements to existing features.
• Major releases are done when significant changes are made to the framework, and will likely require some changes to your application, i.e. breaking changes, but we want to minimise this as much as possible and will offer migration strategies where required.

Pre Releases

Sodacore has a pre-release cycle, which is used to test new features and changes before they are released to the public, these usually will be tagged i.e. alpha, beta, rc, etc.

You can install these via adding the tag to the end of the install command, i.e.

bun install @sodacore/<package>@alpha

Please note that pre-releases are not recommended for production use, and are subject to change, and that these will only appear once we have our first stable release. Although we do appreciate users providing feedback and even taking their production applications and running them on pre-releases to help us identify issues before a stable release.

Deprecation Policy

We will deprecate features and APIs as and when needed, and will provide a deprecation notice in the release notes, and in the documentation.

We will also provide a migration guide for any breaking changes, and will provide a timeline for when the feature or API will be removed.

RFCs

As of right now the project is quite small and mostly unknown, if the project picks up traction and a larger community forms around it, we will likely formalise this process more. As of right now we don't implement any kind of formal RFC process, but if the need arises we will likely implement one.

Experimental Features​

Experimental features are features that are developed for the most part, but require in-the-field testing to ensure they are stable and work as expected. Our framework has a built-in telemetry feature, disabled by default, that allows us to gather anonymous usage data, this mostly consists around, OS/ENV data, specific features and experimental features. We will use this telemetry data to help us identify issues and areas for improvement.