New major?

[func0der]

Hey,

I just stumbled upon Papermerge in a YouTube video the other day.
It had a lot of features and automation stuff in that video. I wanted to try it out.

Then i stumbled upon this in your README.md: https://github.com/ciur/papermerge#papermerge-21-vs-papermerge-20

It is awesome to hear that there is so much effort put into this project.
Either way, I wonder if that project is really in a great position under the version tag 2.1.

I do not know if the term Semantic Versioning is a term you are familiar with. It is a standard that is widely used in the developer world to lay a foundation for understand version numbers.
Semantic versioning usually considers the first number to be the major version of a software/library etc. and the second number behind the first dot to be a feature version, which contains new features without any breaking changes.
Since you are rewriting a backwards incompatible version of this software right now, I would suggest to put this whole endeavor under the flag of a Version 3.

This would also better indicate that there are major changes, which everyone (even non developers) would understand, since most people do not expect Version 3 to work without any hassle with version 4. Or in commercial words: you got to put new money on the table :D

One could also argue that since there is no real migration path from 2.0 to 2.1/3.0 yet, it could be put under the term "beta" or "alpha".
This would prevent people from just "upgrading" to it.
This would go a little against your current stance that 2.1 is stable enough for people to use.

I understand that not everyone is on board with semantic versioning. Best (worst) example is Java or any 4 out of 10 node libraries.
If that is not something you want in your software, I totally understand. In that case I would suggest you state it somewhere. It might be useful for either developers and users alike.

Just wanted to throw this out there :)

Have a happy new year.

[ciur]

I agree that it should have been version 3.0 instead of 2.1.

I am not sure what else to say... maybe, yes I am aware of semantic versioning scheme, but reality is much more complex,
for example: semantic versioning assumes that when you start changes for next version - you already know that it will be "backward incompatible" - which was not the case for me. When I started working on next iteration/refactoring I did not know that it will be "backward incompatible" and thus I promoted application as 2.1.

Also, what is "backward incompatible" ? Semantic version does not define that what exactly "backward incompatibility" is.
Consider this, UI for 2.1 and 2.0 looks almost identical. So, purely from user perspective, applications look very same. Does is count as "backward incompatible" ?

Happy new year!

[func0der]

Also, what is "backward incompatible" ? Semantic version does not define that what exactly "backward incompatibility" is.

It does:

MAJOR version when you make incompatible (public) API changes

source: https://semver.org/

You have to define what your public API is.

Does is count as "backward incompatible" ?

If the owner/admin of the instance has to migrate data or is not able to reuse it, I would say "no".

The "user" it the sense of who is clicking around in the frontend does not care about the version. The admin indeed does care.
You have to define for who you are counting up the versions. Is it for the "user" or the "admins"?

So since this is a self-hosting project, I'd say: it should be the admins.

When I started working on next iteration/refactoring I did not know that it will be "backward incompatible" and thus I promoted application as 2.1.

You could stop next time and create a new major branch and beta version tags :D
Again, not trying to tell you how to manage your applications, just sharing experience :)