Does a pre-release version allow modifications to be made under the same version? #283

New Issue

GiteaMirror · 2026-02-17T11:45:26-06:00

GiteaMirror commented

2026-02-17 11:45:26 -06:00

Originally created by @inkychris on GitHub (Jun 14, 2017).

Section 3 states that:

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

Does this only apply to version numbers without pre-release versioning? For example, can I release a library with version 1.2.3-SNAPSHOT+timestamp multiple times with changes in each one? This might be for each committed change a developer makes while working on the next release. I suppose this may fall under the SHOULD definition in RFC2119 with regard to ignoring build metadata to determine precedence. In which case, would this only be allowed provided the build metadata could be used to determine precedence eg. timestamp?

1.2.3-SNAPSHOT no duplicates?
1.2.3-SNAPSHOT+2017-06-14 and 1.2.3-SNAPSHOT+2017-06-15 not technically duplicate?

I may have answered my own question with regard to build metadata precedence but is this something that could be cleared up in the specification?

Originally created by @inkychris on GitHub (Jun 14, 2017). Section 3 states that: > Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. Does this only apply to version numbers without pre-release versioning? For example, can I release a library with version `1.2.3-SNAPSHOT+timestamp` multiple times with changes in each one? This might be for each committed change a developer makes while working on the next release. I suppose this may fall under the **SHOULD** definition in RFC2119 with regard to ignoring build metadata to determine precedence. In which case, would this only be allowed provided the build metadata could be used to determine precedence eg. timestamp? - 1.2.3-SNAPSHOT no duplicates? - 1.2.3-SNAPSHOT+2017-06-14 and 1.2.3-SNAPSHOT+2017-06-15 not technically duplicate? I may have answered my own question with regard to build metadata precedence but is this something that could be cleared up in the specification?

GiteaMirror closed this issue

2026-02-17 11:45:27 -06:00

GiteaMirror commented

2026-02-17 11:45:28 -06:00

@FichteFoll commented on GitHub (Jun 14, 2017):

I'm confident that pre-releases are also addressed by this restriction. I don't see a reason for them not to.

Regarding metadata, I would consider them a part of the release identifier, i.e. 1.2.3-SNAPSHOT+2017-06-14 and 1.2.3-SNAPSHOT+2017-06-15 are distinct, yet neither has higher precedence than the other.

That said, using a single SNAPSHOT identifier for a pre-release is not a good idea for semver-compliant versioning at all.

@FichteFoll commented on GitHub (Jun 14, 2017): I'm confident that pre-releases are also addressed by this restriction. I don't see a reason for them not to. Regarding metadata, I would consider them a part of the release identifier, i.e. `1.2.3-SNAPSHOT+2017-06-14` and `1.2.3-SNAPSHOT+2017-06-15` are distinct, yet neither has higher precedence than the other. That said, using a single `SNAPSHOT` identifier for a pre-release is *not* a good idea for semver-compliant versioning at all.

GiteaMirror commented

2026-02-17 11:45:29 -06:00

@inkychris commented on GitHub (Jun 15, 2017):

Thanks for your reply! I'm just trying to find a good way of marking internal builds that come from feature branches or merges into master that aren't official releases but is semver-compliant. I'm now thinking perhaps after 1.1.0 for example, any internal build from master would be 1.2.0-adhoc-YYYY.MM.DD.HHmmss.fff even though a timestamp feels a lot more like build metadata. I feel like trying to address versioning on feature branches where they are essentially equal in precedence is beyond the scope of semantic versioning at this time?

@inkychris commented on GitHub (Jun 15, 2017): Thanks for your reply! I'm just trying to find a good way of marking internal builds that come from feature branches or merges into master that aren't official releases but is semver-compliant. I'm now thinking perhaps after `1.1.0` for example, any internal build from master would be `1.2.0-adhoc-YYYY.MM.DD.HHmmss.fff` even though a timestamp feels a lot more like build metadata. I feel like trying to address versioning on feature branches where they are essentially equal in precedence is beyond the scope of semantic versioning at this time?

GiteaMirror commented

2026-02-17 11:45:30 -06:00

@inkychris commented on GitHub (Jun 15, 2017):

There a multiple issues about nightly builds and parallel "channels" etc. (#200, #264, #265, #163) so closing this as reading most of those issues has answered my question. Because my case is with regard to internal releases and not public ones, I'm comfortable with exercising my judgement on when build metadata can be used to determine precedence as these would essentially be disposable builds for developers anyway.

@inkychris commented on GitHub (Jun 15, 2017): There a multiple issues about nightly builds and parallel "channels" etc. (#200, #264, #265, #163) so closing this as reading most of those issues has answered my question. Because my case is with regard to internal releases and not public ones, I'm comfortable with exercising my judgement on when build metadata can be used to determine precedence as these would essentially be disposable builds for developers anyway.

GiteaMirror commented

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

@claell commented on GitHub (Sep 13, 2019):

I'll also link to #6 as I think it is also related.

@claell commented on GitHub (Sep 13, 2019): I'll also link to #6 as I think it is also related.

GiteaMirror referenced this issue

2026-02-17 12:18:47 -06:00

[PR #283] [CLOSED] Add in-page anchors for direct linking #779

Sign in to join this conversation.