Do proper versioning

[Aga-C]

We are doing a fresh start with these forks, so maybe it's a good time to discuss how to version the apps. I always felt that Tibor do it randomly.

My idea is to adhere to Semantic Versioning. Then we would increase versions like following:

• From 0.0.0 to 0.0.1 if we've only done bug fixes (or added translations, I wouldn't consider them features)
• From 0.0.0 to 0.1.0 if we've added new features/enhancements (rather enhancements), but they don't drastically change how app works for the users (past example: swipe down to refresh in File Manager)
• From 0.0.0 to 1.0.0 if we've added big new features/enhancements (past example: adding tasks to Calendar) or removed something what may be significant (support for older APIs, older backups etc.)

There are also cases where we can think whether to increase minor or major versions, because they drastically change how users use the apps, but may not be strictly big features (past example: adding swipe to answer the call instead of the button). In such cases, we should probably discuss what's best. E.g. Firefox or Chrome always increase major version in such case (hence version over 100).

Also, another idea related to versioning - maybe we should restart versioning and release first versions of Fossify apps as 1.0.0?

[naveensingh]

Already planned that. But I'm not so sure about restarting from 1.0.0. Older issues from SMT will have different versions and we will have to jump around to find out what version the user was using.

[Aga-C]

I don't think that restarting version will cause a problem with that. There are still old tags on Git and APKs on F-Droid, so it's easy to come back to old version.

However, I can see other problem - tag naming. We will have a collision with old tags. However, we could adopt different tag naming like v.1.0.0 or release/1.0.0.

[And96]

We may start new versions from 10.0.0 or 7.0.0 ?

[damionx7]

Version can be named according to yyyy.MM.dd eg. 2023.12.29.

[KaKi87]

I'm sorry but you're confusing unstable SemVer (0.y.z) and stable SemVer (x.y.z).

As per the very documentation you linked :

• in either case, x = major, y = minor and z = patch, i.e. there's no major in unstable SemVer, it falls under minor.
• starting values are x = 0, y = 1 and z = 0 for unstable, i.e. it starts at 0.1.0 (not 0.0.0 nor 0.0.1) and x = 1, y = 0 and z = 0 for stable, i.e. it starts at 1.0.0.

Therefore, you :

• either consider the project unstable (probably not since it's an existing app), so you start at 0.1.0 then only increment the 2nd and 3rd digits semantically until you switch to stable ;
• or consider the project stable, so you start at 1.0.0 then increment all digits semantically.

[Aga-C]

0 in the major version in my first post was just an example. Apps are already being released starting from 1.0.0.

[naveensingh]

Yes, we'll start at 1.0.0 and increment semantically.