Bump version to upcoming release

[RayOei]

Current versioning is confusing as it is still 4.9.1, the current production version.

Bumped to new upcoming version 5.0.0
Set to 5.0.0-dev
Updated publiccode.yml as well to indicate current state.
Note: we really should decide on #1199 as constantly pushing current work to master is bad practice in my view.

[github-actions]

🚀 Your preview environment is ready at: https://pr-1264.foodsoft.yksflip.de

[lentschi]

I couldn't find publiccode's docs for this right away, but I suspect developmentStatus shouldn't refer to the current branch, but to the overall state of a software, so I think this should remain stable.

[RayOei]

https://yml.publiccode.tools/schema.core.html
The developmentsStatus is meant for this version. So it is in development.
If there was a publiccode present for 4.9.1 the status will be stable.

[lentschi]

The developmentsStatus is meant for this version.

Where does it say that it's for "this version"? (And what do you mean by "this version" - the current commit one is looking at? That would always be development with the exception of commits tagged with a release version.)

I don't find a clear pointer as to what the developmentsStatus field itself is for. However at publiccode's landing page it does say...

Details carried by a publiccode.yml file include:
title and description of the project [...], development state

That would rather indicate that what they mean is the development state of the project and not that of the current commit. But I can't be certain. @steffen-unicode, who added this, seems to think so too: He added this with developmentStatus: stable even though he surely was aware that state of the repo at the time when he added the commit was development (it was right in the middle of all the article unit business) - but that doesn't matter, as we consider the project as a whole to be stable.

[lentschi]

Btw. if we look at publiccode's own repo they set it to beta in their develop branch even though the name of the branch clearly indicates development:
https://github.com/standard-for-public-code/standard-for-public-code/blob/develop/publiccode.yml#L38

[lentschi]

On top of the single remarks on some of changed files, this PR should add a VERSIONING.md to document our process - see my suggestion for that here: #1199 (reply in thread)

[lentschi]

We should consider removing releaseDate and softwareVersion from this file altogether - see this discussion:
publiccodeyml/publiccode.yml#270

Why do I want to remove them?: They would be hard to maintain (Could be done using automation, but I don't see the point, if they're optional anyways.)
For example, your requested change softwareVersion: 5.0.0 would actually be wrong if we want to merge this PR now - see https://yml.publiccode.tools/schema.core.html#key-softwareversion: It should be the latest stable version, which currently is 4.9.1. So if we stick to our agreement here, this would almost always be one release version before the one in VERSION.

[RayOei]

I have to disagree.

The publiccode group is also clearly still in flux on what they mean. See for instance the Italian chapter (as Italy is the only country to date which mandates it) where github workflow will update versions based on what the codebase has defined: https://github.com/italia/publiccode-softwareversion-check-action/tree/master, which would be my approach as well. As it sensible to have versioning maintained at one spot so there is only one truth.

"This versions" is in essence any branch you work on the codebase has a state of its own. Any branch could potentially lead to a releasable product. If you only focus on the main branche: the HEAD of master is a 'future' release. If you were to release at that point it should reflect its state and therefore its version. I think there is no argument there, right?
When v4.9.1 was released, any new commit will be a different, newer, version. Therefore any information at that point should target the future upcoming release. This is also true for the publiccode information. It just doesn't make any sense to have it indicate a version you already passed. You always version your codebase to the upcoming release. Be it a alpha version, a beta trial or a formal 'end' release. Any release made to the public will have its own version information.

Anyway... before we lost in a discussion about the merit of publiccode, the safest choice is to just remove it. Or at least the version information. 🤷

[lentschi]

Anyway... before we lost in a discussion about the merit of publiccode, the safest choice is to just remove it. Or at least the version information.

Yes, if you'd do that it would be great. 👍 We can add it back in later once we have come to an agreement in #1199.

[lentschi]

IMO the CHANGELOG.md should only be modified right before (at the moment of) a release. See our decision here. Or was there still something open in our discussion? (If so, let's continue there!)

[RayOei]

I am not sure whether the "should only" means that you "should NOT" do it before or that it only means "it has to be done" before a release?

Atlhough not a breaking point: I believe a changelog can be updated at any time. In general it is easier to update when major changes are merged. E.g. the changelog comment is already part of the branch being merged. It is less work when a release is prepared when most of it is already documented. On the other hand there is no particular problem of not having an up-to-date changelog when working towards a release. It only means somebody has to go over the merges and issues and collect what needs to be mentioned on the changelog.

[lentschi]

It is less work when a release is prepared when most of it is already documented.

Yes, handling it that way in the future is something I have pondered too and we could discuss it.
But putting this aside, in this PR you want to add two lines to the file.

1. The first of them adds little information and might even be misleading: Foodsoft 5.0.0 is not the latest version, but assumed to be the upcoming version (The VERSION file containing the upcoming version is one thing, but listing the upcoming version on the same level as released versions in the same file seems confusing to me.)
   Also, see publiccode's own CHANGELOG for example - it only contains their latest release version, not the changes from back then until now.
   It would still be fine if we handled it differently from them, but then at least I would write UPCOMING instead of 5.0.0 to avoid confusion. And adding it as it is in the PR now makes little sense to me. If we were to do it, we'd have to compile the full list of changes since the last release in the same PR.
2. The second line is simply wrong: Nothing has been released on 2026-01-07 - we don't have a release date yet. It would have to read TBA.