Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get releases in sync #807

Open
mikkeschiren opened this issue Dec 25, 2024 · 2 comments
Open

Get releases in sync #807

mikkeschiren opened this issue Dec 25, 2024 · 2 comments

Comments

@mikkeschiren
Copy link

mikkeschiren commented Dec 25, 2024

Summary

The dev release of Matomo (5.x-dev) has pull requests accepted and merged after 5.2.0 that is not present in 5.2.1.

The releases of Matomo, is from my perspective, confusing. Things are merged into the ongoing dev branch that is not present in releases that come between releases - the diff between what was in Matomo 5.2.0 doesn't compare what is in 5.2.1, looking at merged pull requests. Milestones could be open for releases that are already out (like 5.2.1 - that has a planned release date in march 2025, but are already out, and closed issued, and open issues, that are not present in 5.2.1).

Is there a possibility to have documentation in place how releases are handled?

@michalkleiner
Copy link
Contributor

Hi @mikkeschiren, thanks for you question/suggestion.

Matomo follows semantic versioning for its releases and 5.x-dev branch is the latest dev work branch where new features can be merged into. It is the branch that a next minor version will be created from. If we were to develop changes that would be breaking backwards compatibility or were of major significance, those would need to wait for next major version, i.e. Matomo 6 in this case. When we start working on things like that, we will create 6.x-dev branch for it. An lastly, for patch level releases, in the current minor 5.2.x line, we have 5.2.x-dev branch, into which only patch changes and bug fixes are merged that can be released in a patch version release, where it's safe to automatically update while being certain nothing else will break and that no new behaviour or enhancements are introduced.

You can read a bit more about it e.g. on https://www.geeksforgeeks.org/introduction-semantic-versioning/.

On the point that 5.2.1 can have slightly different code than what's been merged to 5.x-dev after 5.2.0 was released — yes, we have a merge up strategy and all changes that are only added to a patch version they will eventually end up also in the 5.x-dev branch. We either merge all the changes at once or create individual PRs for each fix, as we see fit. You can rest assured that next minor version will have all its previous versions' code.

I will move this issue to the documentation repository where we will consider whether Matomo documentation needs changing or adding to around this process.

@mikkeschiren
Copy link
Author

Yeah, this is the right place for the discussion, so good to have moved it.

Why I am noting this at this stage is that where a bug for many users in 5.2.0, an update to Tag Manager, the patch for the fix were merged, but later on 5.2.1 was released without this fix, leaving Tag Manager broken for many users.

The projects I have been engaged in never do releases where the latest fixes in the upstream is not included. For me, as a developer, this is a bit confusing :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants