Project stability?

[karolyi]

Hey,

I'm the guy who wants to build a FreeBSD package out of this project but the huge version jumps confuse me.

The project just jumped from v17.5 to v25 without any version numbers in between, including a lot of breaking changes. So it automatically makes me wonder, is this project supposed to be stable enough for production usage? If APIs break left and right, devs would find it hard to keep using this project.

I'd appreciate some feedback about the roadmap. I welcome the fast paced development (can't vouch for the code stability though), but if the project can't be considered having a stable API, I'm not sure it's worth keeping up with the packaging hassle.

[karolyi]

ping

[sanikolaev]

Hi @karolyi

without any version numbers in between

There were versions in between. They're all listed here https://manual.manticoresearch.com/Changelog#Version-25.0.0

I understand it may be confusing for users and contributors, but here's how it works:

• Each commit that changes how Manticore Search works increases its version. This makes sense because:
  • we don't want to say "it works since commit abcdefghi on Feb 15th." Instead, we can say "it works since version 1.2.3."
  • it makes it easier to understand how many improvements we make and what kind they are
  • it makes dev versions easy to use (e.g., just the Docker image manticoresearch/manticore:dev-25.0.7).
• We try to be fair to users and increase the first number in the version (MAJOR in semver) whenever there is ANY incompatibility, for example between:
  • Manticore Search and its components (mostly MCL)
  • The user's app and Manticore Search (for example, If an existing command starts returning something different which may break users' apps.)
  • Data format
  • Replication format
  • etc

What this means:

• If the MAJOR version does not change, you can be sure that compatibility stays the same and there's nothing to worry when upgrading to the new version. This is different from some other software that introduces incompatibilities without increasing the major version. They may avoid doing so because they worry users will hesitate to upgrade, but this can cause problems later. In our case, if the major version stays the same, you can upgrade without checking the changelog.
• If the MAJOR version changes, it's a good idea to check the changelog. This helps users:
  • Find new features that may be useful
  • Understand what they need to change in their app
  • Learn how to migrate to the new version

[karolyi]

Thanks ChatGPT, but this was only partially answering my question.

If manticore often releases breaking changes (as it is with major semver version changes), devs will just as much often need to adjust their programs to suit the changes. Hence the rightful question: is there a roadmap or you release stuff as you go, breaking compatibility randomly?

Is there a "stable" API planned?

[tomatolog]

you could find the roadmap at Manticore public roadmap (large tasks only planned for the nearest future, not bugfixes / smaller issues)
as it was explained above any major \ breaking changes will increase major version

if you need stable api you could stick to the some version you needed and use our support service to backport all bug fixes in this version without any further features or breaking changes

[sanikolaev]

devs will just as much often need to adjust their programs to suit the changes

That may be a wrong assumption. Devs often need to check the changelog, not just adjust their programs. The point is that compatibility breaks can vary in severity. In most cases, a compatibility break doesn't actually affect most.

For example, Manticore 25.0.0 may still be able to read data from Manticore 3. (though I haven't checked). Another point is that we don't always know which breaking changes matter and which don't. Other companies decide this themselves, which can lead to surprising failures after switching to a new "minor" version.

We choose to mark any breaking change with a major version increment. It seems more logical.