initiate blogpost for v0.53.0

docs/blog/posts/v0.53.0.md

@@ -0,0 +1,204 @@
+---
+date: 2026-01-31
+categories:
+  - Release notes
+---
+
+# Release v0.53.0
+
+Welcome to Perses v0.53.0! In this release, on top of many improvements and bug fixes, we have introduced several
+changes that break the compatibility with previous versions. Please review the breaking changes section carefully before
+upgrading.
+
+These changes have been thinking carefully to improve the overall user experience and maintainability of Perses. We hope
+even if it will make the upgrade process a bit more complex, you will stay with us and enjoy the benefits of these
+improvements.
+
+While you can read this blog post to have details about the changes and how to upgrade, we are also providing a
+migration guide that is more condensed and focused on the steps required to upgrade from previous versions to v0.53.0.
+
+// TODO: Add link to migration guide when available
+
+On a different topic, we are happy to being able to list [Logz.io](https://logz.io/) as a new officially company using
+Perses in production. Welcome to the Perses community!
+
+If you are a company using Perses or contributing to it and want to be listed as an adopter, please follow
+the [guideline](../../adopters.md). It is always great to see more and more companies trusting Perses for their
+monitoring needs. And it will help us to grow the community and make Perses even better.
+
+<!-- more -->
+
+## Introduction of plugin version and registry
+
+To enhance the management of plugins specially when dealing with upgrading a plugin version that may introduce breaking
+changes, we introduced a new field in the plugin specification called `metadata`. It includes a `version` field that
+allows to specify the version of the plugin and the `registry` field that indicates the source registry of the plugin.
+
+Now a plugin specification looks like this:
+
+```yaml
+kind: TimeSeriesChart
+metadata:
+  version: v0.1.0
+  registry: perses.dev
+spec:
+# ... rest of the plugin spec
+```
+
+Note that the version is following the semantic versioning format (semver) and this is enforced during the loading of
+the plugin.
+
+This change is important as it will allow in the future to manage multiple versions of the same plugin and facilitate
+the migration from one version to another. We are planning to introduce automatic migration tools in future releases to
+help users upgrade their plugins seamlessly. Excepting if a plugin is introducing breaking changes that cannot be
+automatically handled, the upgrade process will be handled by the Perses backend using cuelang script contained in the
+plugin package.
+
+### What does it change?
+
+For **end users** using the Perses application, this change is transparent and does not require any action.
+
+However, for **plugin developers**, you will need to update the CLI to the last version. This is required as the API
+handling the load of the plugins in development has changed. Therefore, previous versions of the CLI won't be able to
+send the data to the server to load plugin in development. The error returned by the server will be 405 (Method Not
+Allowed). (see https://github.com/perses/perses/issues/3789)
+
+If you want to see the changes and more details regarding how it is implemented, they are available in this
+PR: https://github.com/perses/perses/pull/3711
+
+## TLS config changes
+
+We are introducing a breaking change in the TLS configuration to have a consistent syntax to define TLS settings across
+all data-sources specifications and across all backend sub configurations.
+
+The previous version was mixing two syntaxes to set TLS across the various possible configuration that could lead to
+confusion (camelCase and snake_case).
+This breaking change is impacting only the SQL database configuration.
+
+In the SQL configuration, if the tls_config is used, then you should change your config like that:
+
+```txt
+ca_file -> caFile
+cert_file -> certFile
+key_file -> keyFile
+server_name -> serverName
+insecure_skip_verify -> insecureSkipVerify
+min_version -> minVersion
+max_version -> maxVersion
+```
+
+## User used in the container
+
+In order to simplify the build of the docker image, we have changed the default user used in the container from `nobody`
+to `nonroot`. As a based image we are using now `gcr.io/distroless/static-debian12:non-root` instead of
+`ggcr.io/distroless/static-debian12:latest`, which gives us a non-root user by default.
+
+### What does it change?
+
+This change can impact users that is using as a database the file system inside the container, specially when running
+the container with docker (not within Kubernetes). In that case, you should ensure that the `nonroot` user has the right
+permissions to read and write into the database folder. If this is not the case, when upgrading the image, you will face
+permission errors when Perses is trying to load the data coming from the file system.
+
+## Query editor changes
+
+// TODO find a better title more explanatory + explain what has changed.
+
+### What does it change?
+
+If you are developing plugin specially query plugin, these changes will impact you, and you need to follow these
+guidelines.
+
+`MultiQueryEditor` component has a new mandatory method: `onQueryRun`. It will be called when the user click on the
+button "Run Query". It's useful if you want to execute a query only when this button is clicked and not on every
+onChange (previous Perses behavior).
+
+Your code should change from this:
+
+```tsx
+export function FooExplorer(): ReactElement {
+    const {
+        data: {queries = []},
+        setData,
+    } = useExplorerManagerContext<FooExplorerQueryParams>();
+
+    return (
+        <Stack gap={2} sx={{width: '100%'}}>
+            <MultiQueryEditor
+                queryTypes={['ProfileQuery']}
+                queries={queries}
+                onChange={(newQueries) => setData({queries: queryDefinitions})}
+            />
+            <FooPanel queries={queries}/>
+        </Stack>
+    );
+}
+```
+
+to this:
+
+```tsx
+export function FooExplorer(): ReactElement {
+    const {
+        data: {queries = []},
+        setData,
+    } = useExplorerManagerContext<FooExplorerQueryParams>();
+
+    const [queryDefinitions, setQueryDefinitions] = useState<QueryDefinition[]>(queries);
+
+    return (
+        <Stack gap={2} sx={{width: '100%'}}>
+            <MultiQueryEditor
+                queryTypes={['ProfileQuery']}
+                queries={queryDefinitions}
+                onChange={(newQueries) => setQueryDefinitions(newQueries)}
+                onQueryRun={() => setData({queries: queryDefinitions})}
+            />
+            <FooPanel queries={queries}/>
+        </Stack>
+    );
+}
+```
+
+## Variable migration changes
+
+// TODO
+
+## Introducing i18n support
+
+// TODO
+
+## CLI improvements
+
+- `plugin test-schemas` has been improved to test that the actual migrated schemas are valid against the expected
+  schemas.
+- `plugin start` is now able to discover the port used by rspack to serve the plugin in development mode, so you don't
+  need to provide it anymore.
+    - There was also an issue when loading a plugin in development with no schema defined, it is now fixed.
+    - When stoping the command, there was some orphan process left, it is now fixed.
+    - As mentioned before, the CLI has been updated to be compatible with the new dev plugin API introduced in this
+      release.
+- `lint`: when you were using local plugin to validate the dashboards, it was mandatory to have the plugins extracted in
+  a folder. Now you can also provide the plugins as an archive like it is the case for the Perses server. The command
+  will extract the plugins before starting validating any data.
+
+## Plugin improvements
+
+// TODO list of improvements, ideally give major changes and improvements for each plugin.
+
+### Support of temperature units
+
+// TODO
+
+### Introducing VictoriaLogs and ClickHouse as new data-sources
+
+On top of that, this release is also introducing two new data-sources: VictoriaLogs and ClickHouse provided directly by
+the community.
+
+// TODO: write more about these two data-sources, highlight their features, and who did it.
+
+Note that since these two data-sources are provided by the community, they are not officially supported by the Perses
+team.
+And as such, soon we will come with a governance model to manage community plugins. In later release, these plugins
+might be removed in the main images, depending on the governance adopted. You will still be able to use them by
+installing the datasources in your Perses instance.