Bump version to upcoming release #1264
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,5 @@ | ||
| # [Foodsoft 5.0.0](https://github.com/foodcoops/foodsoft/compare/master...v4.x) | ||
| (2026-01-07) | ||
|
|
||
| ### Bug Fixes | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| 5.0.0 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,13 +2,13 @@ | |
| # metadata file that makes public software easily discoverable. | ||
| # More info at https://github.com/italia/publiccode.yml | ||
|
|
||
| publiccodeYmlVersion: '0.5' | ||
| name: Foodsoft | ||
| url: 'https://github.com/foodcoops/foodsoft.git' | ||
| landingURL: 'https://foodcoops.net' | ||
| releaseDate: '2026-01-06' | ||
| softwareVersion: v5.0.0 | ||
|
Contributor
There was a problem hiding this comment. We should consider removing 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.)
Member
Author
There was a problem hiding this comment. 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? 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. 🤷
Contributor
There was a problem hiding this comment.
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. |
||
| developmentStatus: development | ||
|
Contributor
There was a problem hiding this comment. I couldn't find publiccode's docs for this right away, but I suspect
Member
Author
There was a problem hiding this comment. https://yml.publiccode.tools/schema.core.html
Contributor
There was a problem hiding this comment.
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
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
Contributor
There was a problem hiding this comment. Btw. if we look at publiccode's own repo they set it to beta in their |
||
| platforms: | ||
| - web | ||
| softwareType: standalone/web | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the
CHANGELOG.mdshould 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!)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
5.0.0is not the latest version, but assumed to be the upcoming version (TheVERSIONfile 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
UPCOMINGinstead of5.0.0to 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.2026-01-07- we don't have a release date yet. It would have to readTBA.