mirror of
https://github.com/semver/semver.git
synced 2026-03-09 15:32:03 -05:00
Need better rules for sorting ascii build id part #38
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#38
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @wolandscat on GitHub (Oct 3, 2012).
The semver.org spec is excellent, and have specified it for use in software-like artefacts in openEHR.org. The only problem is this part of rule 12:
Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.
This is ok for the set of strings 'alpha', 'beta', 'rc-xxx', because they happen to sort in the same order as the lifecycle, but a more general case should be documented in our view, which says that for any given lifecycle consisting of a certain set of states, the order is specified by that lifecycle. So another lifecycle could be made of states like 'pre-draft', 'draft', 'review', 'published', 'obsolete', and the state machine would specify valid transitions.
Given that this part will always be lifecycle specific, I think it would be worth documenting the alpha/beta/rc lifecycle for what it is, and possibly even some other example lifecycles.
Hope this is useful.
@Tieske commented on GitHub (Oct 3, 2012):
Though I see the point, on a meta view this is sort of bending the standard to a specific implementation. Where the purpose of a standard is bending implementations towards the standard.
So I disagree with this. It would make semver structurally weaker.
@haacked commented on GitHub (Oct 3, 2012):
I agree with @Tieske here. That would severely limit the ability to reason about a version when any given version might have different semantics based on their lifecycles.
One way to map your lifecycle within the bounds of SemVer is to map them to a prerelease number by convention. For example:
1.0.0-0.pre-draft1.0.0-1.draft1.0.0-2.review1.0.0-3.published@wolandscat commented on GitHub (Oct 3, 2012):
On 03/10/2012 21:49, Thijs Schreijer wrote:
Maybe you see semver as a kind of rigid rule set for all software
production. I have no problem with that, we need it. But the model can
be applied more widely, and there are many many kinds of formal
artefacts that need the same rigour of version identification, but
simply don't have the same alpha/beta/rc lifecycle as the classic
standard - including software-like artefacts, technical model artefacts,
and documents. In fact, a lot of institutional software lifecycles don't
exactly follow that set of states. Institutions already don't adopt
standards when the standards don't fit their needs, they break them. I
know this because I have worked on standardisation in e-health for the
last 18 years, and before that on software lifecycle and document
management in typical corporations that come up with their own standards.
For things with more complex, and well understood lifecycles, variants
of semver will be needed, but there is no question of using 'alpha',
'beta' etc.
So it seems to me there are the following options:
that as its scope.
o this is already very useful, and if the aim is only to make
software releasing sane and ignore other artefact types and
production, it should help a lot.
create other variants with a plug-in rule 12, and a template for the
generalised form
rule 12 is a plug-in rule, and define the software variant using the
current rule 12.
For our own purposes it's easy enough - we can specify a copy of the
current specification, with a replaced rule 12. I just think it would be
useful to indicate how the same approach would apply to all technical
artefact release management, not just software. Then semver would apply
to huge numbers of other artefacts.
**
@haacked commented on GitHub (Oct 4, 2012):
At the moment, I think it makes sense to keep SemVer narrowly scoped. Its semantics are already embedded in existing package managers and other software.
Note that even for software, the pre-release rule doesn't necessarily handle all cases. For example, Microsoft often calls software releases "Previews". So you'd have
1.0.0-preview-1,1.0.0-preview-2,1.0.0-beta, 1.0.0. Such an ordering doesn't fit the SemVer semantics.But even that's easy enough to fix. They simply draw a distinction between a "product" version (the version they market) and the actual library version.
@Tieske commented on GitHub (Oct 23, 2012):
My guess would be that they do not follow the standard, or created their own, becasue there is no standard. And thats exactly what SemVer is trying to establish. And if anyone creates a deviating standard, thats fine, just don't call it SemVer, but give it a proprietary name as well as a proprietary order.
@haacked commented on GitHub (Dec 20, 2012):
Yep! It's pretty easy to have a more restrictive stricter spec for your needs that's also SemVer compliant.