[GH-ISSUE #607] does losing backwards compatibility for a suckless-style config amount as major version? #6419

New Issue

GiteaMirror · 2026-06-17T05:12:06-05:00

GiteaMirror commented

2026-06-17 05:12:06 -05:00

Originally created by @al-caveman on GitHub (Aug 14, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/607

so i have an app that i modified such that:

the cli arguments did not change. same arguments and same behaviour.
the database format did not change. same thing.

what is changed is this:

removed some redundant prompts by making the app remember the previous choices. so the user is no longer asked to enter same input again. this does not warrant a major version, right? i guess only a minor version increment?
variable names and value syntax in configuration file. now, this is the tricky part, because the app does not have have a configuration file. its configuration is in the source code itself, typical to suckless apps, such as st (where user modified source code, then recompile app).

so, my question is:

is configs-in-source-code considered a configuration file? or is it considered without configuration file?
where do i fit for changing configuration variable names and their values' types?

if a user goes into the older version, copies part of the source code which is intended to store configs, and pastes it in the same region in the new app, the app will crash, because variable names have changed, as well as their value types.

what does semver think?

Originally created by @al-caveman on GitHub (Aug 14, 2020). Original GitHub issue: https://github.com/semver/semver/issues/607 so i have an app that i modified such that: - the cli arguments did not change. same arguments and same behaviour. - the database format did not change. same thing. what is changed is this: - removed some redundant prompts by making the app remember the previous choices. so the user is no longer asked to enter same input again. this does not warrant a major version, right? i guess only a minor version increment? - **variable names and value syntax in configuration file**. now, this is the tricky part, because the app does _not_ have have a configuration file. its configuration is in the source code itself, typical to suckless apps, such as `st` (where user modified source code, then recompile app). so, my question is: - is configs-in-source-code considered a configuration file? or is it considered without configuration file? - where do i fit for changing configuration variable names and their values' types? if a user goes into the older version, copies part of the source code which is intended to store configs, and pastes it in the same region in the new app, the app will crash, because variable names have changed, as well as their value types. what does semver think?

GiteaMirror closed this issue

2026-06-17 05:12:07 -05:00

GiteaMirror commented

2026-06-17 05:12:08 -05:00

@ljharb commented on GitHub (Aug 14, 2020):

removed some redundant prompts

arguably either one; if the user wants to be able to enter the info every time, it'd be breaking for them; otherwise minor.

changing the config format is absolutely a breaking change, because that is a part of your API.

@ljharb commented on GitHub (Aug 14, 2020): > removed some redundant prompts arguably either one; if the user *wants* to be able to enter the info every time, it'd be breaking for them; otherwise minor. changing the config format is absolutely a breaking change, because that is a part of your API.

GiteaMirror commented

2026-06-17 05:12:08 -05:00

@al-caveman commented on GitHub (Aug 14, 2020):

i see. just to confirm. breaking change = major version bump?

@al-caveman commented on GitHub (Aug 14, 2020): i see. just to confirm. breaking change = major version bump?

GiteaMirror commented

2026-06-17 05:12:09 -05:00

@ljharb commented on GitHub (Aug 14, 2020):

Yes.

@ljharb commented on GitHub (Aug 14, 2020): Yes.

GiteaMirror commented

2026-06-17 05:12:10 -05:00

@al-caveman commented on GitHub (Aug 14, 2020):

Thanks. Makes sense.

@al-caveman commented on GitHub (Aug 14, 2020): Thanks. Makes sense.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6419