Non-code changes between releases #185

New Issue

GiteaMirror · 2026-02-17T11:31:16-06:00

GiteaMirror commented

2026-02-17 11:31:16 -06:00

Originally created by @Maikuolan on GitHub (Jul 4, 2015).

Hi,

For a particular project of mine, I'm not currently using semver, but what I'm currently using is adequately close enough to semver that I feel that it should be possible to migrate over to semver from what I'm currently using if I was to plan it correctly, and I'm thinking about doing that.

Quick question.

For a project of a nature that may potentially contain changes between individual releases that don't have anything to do with code (such as, for example, changes to documentation, configuration defaults or periferal files that the code uses, but which in and of themselves, strictly speaking, aren't code), how would you go about incrementing your version numbers?

Say, for example, Project X is versioned as 1.2.3 at current release, and then a month later, it's re-released with some modified documentation (such as i18n/i10n README translations, for example) or some other modified internal files that aren't code and don't contain code (such as signature files, as could be the case for anti-virus programs, for example). Would this re-release be considered a "patch", and would it therefore be versioned as 1.2.4? Could I version it as something like 1.2.3-r1 (where "r" == release number)? Does semver encourage a different approach, or is there such an approach recommended by semver at all? Or would I be better to simply use my own discretion (and would I be compliant with semver recommendations if I did)?

Thanks. :-)

Kind Regards,
Caleb M / Maikuolan.

Originally created by @Maikuolan on GitHub (Jul 4, 2015). Hi, For a particular project of mine, I'm not currently using semver, but what I'm currently using is adequately close enough to semver that I feel that it should be possible to migrate over to semver from what I'm currently using if I was to plan it correctly, and I'm thinking about doing that. Quick question. For a project of a nature that may potentially contain changes between individual releases that don't have anything to do with code (such as, for example, changes to documentation, configuration defaults or periferal files that the code uses, but which in and of themselves, strictly speaking, aren't code), how would you go about incrementing your version numbers? Say, for example, Project X is versioned as 1.2.3 at current release, and then a month later, it's re-released with some modified documentation (such as i18n/i10n README translations, for example) or some other modified internal files that aren't code and don't contain code (such as signature files, as could be the case for anti-virus programs, for example). Would this re-release be considered a "patch", and would it therefore be versioned as 1.2.4? Could I version it as something like 1.2.3-r1 (where "r" == release number)? Does semver encourage a different approach, or is there such an approach recommended by semver at all? Or would I be better to simply use my own discretion (and would I be compliant with semver recommendations if I did)? Thanks. :-) Kind Regards, Caleb M / Maikuolan.

GiteaMirror closed this issue

2026-02-17 11:31:16 -06:00

GiteaMirror commented

2026-02-17 11:31:17 -06:00

@FichteFoll commented on GitHub (Jul 5, 2015):

Increase patch. Patch is the smallest release identifier number.

1.2.3-r1 is a pre-release and the exact opposite of what you want.

@FichteFoll commented on GitHub (Jul 5, 2015): Increase patch. Patch is the smallest release identifier number. `1.2.3-r1` is a pre-release and the exact opposite of what you want.

GiteaMirror commented

2026-02-17 11:31:18 -06:00

@Maikuolan commented on GitHub (Jul 5, 2015):

Cheers FichteFoll; I appreciate the help. :-)

@Maikuolan commented on GitHub (Jul 5, 2015): Cheers FichteFoll; I appreciate the help. :-)

GiteaMirror referenced this issue

2026-04-16 10:05:38 -05:00

[GH-ISSUE #185] Bad example #990

GiteaMirror referenced this issue

2026-04-20 09:33:55 -05:00

[GH-ISSUE #185] Bad example #1857

GiteaMirror referenced this issue