Property talk:P348

From Wikidata
Jump to navigation Jump to search

Documentation

software version identifier
numeric or nominal identifier of a version of a software program or file format, current or past
DescriptionVersion numbers of versions of the software. Qualify with version type (P548) and point in time (P585).
Representssoftware version (Q20826013), version number (Q114469879)
Data typeString
Domain
According to this template: software (Q7397)
According to statements in the property:
software (Q7397), file format (Q235557), programming language (Q9143), data set (Q1172284), website (Q35127), video game (Q7889), work (Q386724), public license (Q7257461), technical standard (Q317623), software component (Q17176533), computing platform (Q241317) or keyboard layout (Q725744)
When possible, data should only be stored as statements
Allowed values
According to this template: [words] [comparator] digits[.digits[.digits]][letters] [build/rc/alpha/beta/-/ digits] [(text name)][*/+/ - version/ .. version],
According to statements in the property:
.{1,200}
When possible, data should only be stored as statements
ExampleBugzilla (Q55671) → 4.5.1
Avast Antivirus (Q1574) → 2014.9.0.2016.330
AWK (Q213970) → IEEE Std 1003.1-2008
AmigaOS (Q380526) → 4.1 Update 6
Java platform (Q1713118) → 7 Update 51
Plan 9 (Q725779) → Fourth Edition
Windows Internet Explorer 8 (Q841259) → 8.0.6001.18702IC
Composer (Q15252222) → 1.0.0-alpha8
AIMP (Q293825) → 3.55 Build 1324
Erlang (Q334879) → R16B03
Kubuntu (Q11250) → 13.04 (Raring Ringtail)
Microsoft Office (Q11255) → 15.0.4551.1011
Microsoft Office (Q11255) → 2011 (14.3.9 SP3)
CrunchBang Linux (Q11983) → 11 20130506 (Waldorf)
MariaDB (Q787177) → 10.3.9
Internet Explorer 10 (Q819537) → 10.0.9200.16521 RTM
Pokémon Go (Q20966579) → 0.35.0
Mozilla Firefox (Q698) → 52.2.1 ESR
Lua (Q207316) → > 5
Format and edit filter validationAbuse filter #61
Tracking: sameCategory:P348 same on Wikidata (Q32069410)
Tracking: differencesno label (Q32069376)
Tracking: usageCategory:Pages using Wikidata property P348 (Q20989971)
Tracking: local yes, WD noCategory:Software version not in Wikidata, but available on Wikipedia (Q26467729)
See alsotabular software version (P4669)
Lists
Proposal discussion[not applicable Proposal discussion]
Current uses
Total797,146
Main statement792,48199.4% of uses
Qualifier4,6010.6% of uses
Reference64<0.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P348#Type Q7397, Q235557, Q9143, Q1172284, Q35127, Q7889, Q386724, Q7257461, Q317623, Q17176533, Q241317, Q725744, SPARQL
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P348#allowed qualifiers, SPARQL
Format “.{1,200}”: value must be formatted using this pattern (PCRE syntax). (Help)
List of violations of this constraint: Database reports/Constraint violations/P348#Format, hourly updated report, SPARQL
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P348#Scope, SPARQL
Allowed entity types are Wikibase item (Q29934200), Wikibase property (Q29934218): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P348#Entity types
Citation needed: the property must have at least one reference (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P348#citation needed
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Qualifiers[edit]

I report this discussion on the project chat (Wikidata:Project_chat/Archive/2013/04#Property:P348 - Stable_version (software only)) regarding the qualifiers properties. --Viscontino talk 08:45, 5 April 2013 (UTC)[reply]

Qualifiers are available now, I think we could change the name of this property. The only things we need is a qualifier property (something like "state" or similar, a property which has a general use) and an item where we could link to. (I couldn't find an existing item for "stable version", they might be an item in other languages?) --#Reaper (talk) 13:16, 27 April 2013 (UTC)[reply]
I support this idear. Is their any current discussion about that, because the property name is still "stable version"? --Stiegenaufgang (talk) 16:55, 5 June 2014 (UTC)[reply]
✓ Done. John Vandenberg (talk) 02:01, 19 September 2014 (UTC)[reply]

German translation[edit]

I think the German translation of this property should be updated, because it has a different meaning than the English one.

  • stabile Version → Version (englː version)
  • aktuell stabile Version der Software → stabile Version der Software (englː stable version of the software)

Stiegenaufgang (talk) 23:23, 15 November 2014 (UTC)[reply]

Constraint:Qualifiers[edit]

Recently I have added the constraint on qualifiers but there are some discrepancies (many qualifiers were added by me):

Matěj Suchánek (talk) 17:05, 22 December 2014 (UTC)[reply]

Delete old versions?[edit]

Just to be clear: Should we delete statements with old, superseded versions? (Except if there are multiple development branches, like GnuPG 1.4.x and 2.x.) —DSGalaktos (talk) 14:11, 26 March 2015 (UTC)[reply]

Some links (I suppose Wikidata could handle more versions, using qualifiers and ranks): Wikidata:Bot requests/Archive/2013/04#Keeping last stable software version up to date, Wikidata:Requests for permissions/Bot/SamoaBot 8, Wikidata:Project chat/Archive/2013/04#Property:P348 - Stable version (software_only), Wikidata:Project chat/Archive/2014/12#Unintentional removal of statements in software version identifier (P348), Wikidata talk:Abuse filter#Version. Matěj Suchánek (talk) 16:43, 26 March 2015 (UTC)[reply]
So from the last two links I take it the statements are supposed to stay? —DSGalaktos (talk) 22:14, 26 March 2015 (UTC)[reply]
Yes :) ·addshore· talk to me! 00:05, 27 March 2015 (UTC)[reply]
Does this "Yes" answer the last question or the question in the heading? I guess it's a "yes" again ;) Brevity (talk) 20:40, 2 August 2016 (UTC)[reply]
There is a scalability problem with this. I'm thinking of "rapid release cycles", see w:History of Firefox, w:Firefox version history, w:Google Chrome version history… Even worse, some web applications are tagging new versions like, more than weekly (e.g. Laravel releases, and I guess we could easily find even more frequently released applications). Od1n (talk) 20:19, 6 March 2017 (UTC)[reply]

Overuse of this property for licenses[edit]

I have seen this property in (mis-)use for licenses, i.e. Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220). I am not sure if it is a good idea to mix both, especially since this property explicitly states it is for software.

Maybe there should be a new property specifically for license versions. What do you think? --Wiki-Wuzzy (talk) 22:41, 15 April 2015 (UTC)[reply]

@Wiki-Wuzzy: Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220)software version identifier (P348)2.0 should be replaced with Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220)edition number (P393)2.0 Iwan.Aucamp (talk) 13:26, 22 May 2020 (UTC)[reply]

How to mark the latest stable version when older versions are kept[edit]

Use three seashells small boxes on the left of the date to mark the latest version as "Preferred rank". Don't forget to mark the older version(s) as "Normal (or deprecated) rank". The RedBurn (ϕ) 11:21, 25 May 2015 (UTC)[reply]

Just a small follow-up question: Should the current version be marked as preferred and older versions as normal, or the current version as normal and the older versions as deprecated? --1-Byte (talk) 14:21, 1 February 2016 (UTC)[reply]
Is that the recommended way of doing that? The first try of changing the rank of an old version to “deprecated” yields a warning that says setting to deprecated is “also incorrect”. --AVRS (talk) 18:42, 28 March 2016 (UTC)[reply]

How to mark a version as unstable[edit]

See P548 Talk: add a qualifier "type of version", which current possible values are "alpha version" and "beta version". The RedBurn (ϕ) 13:01, 25 May 2015 (UTC)[reply]

Be sure to add a qualifier "type of version" with value Q19972162 (stable version) to at least the latest stable version to make it possible to selectively retrieve it from a template. The RedBurn (ϕ) 16:27, 25 May 2015 (UTC)[reply]

Labels and descriptions are wrong[edit]

For example, in Ukrainian, this property is labelled as "стабільна версія", with the description "остання стабільна версія програмного забезпечення". "стабільна" means "stable", "остання" means "last". Of course, people will continue to delete non-last and non-stable versions. — Vort (talk) 07:36, 4 December 2015 (UTC)[reply]

I just went through the label list and removed loads of outdated labels and descriptions that looked like they included “latest” or “stable”. Main edit, auxiliary edits. I probably broke some grammar, so it would be great if people actually speaking these languages could review the changes and fix problems. Also, I wasn’t able to fix Icelandic, because has edition or translation (P747) has a conflicting label. —Galaktos (talk) 10:20, 4 December 2015 (UTC)[reply]
Thanks. — Vort (talk) 13:37, 4 December 2015 (UTC)[reply]

Don't keep old versions[edit]

Regarding the software items I came across, none had a complete listing of versions (as eg compared to the list of releases on GitHub). Version lists just started with the version that was current when the item was created, and had "holes" in the list of newer/updated versions. Thus, the list of version numbers is irrelevant and misleading (eg you cannot compare counts/periodicity of version number updates across software items, which could be interesting facts). IMO, only the newest one(s) should be kept. --Brevity (talk) 20:20, 2 August 2016 (UTC)[reply]

Some articles have tables of versions, for which Wikidata could be referred to. --AVRS (talk) 21:21, 2 August 2016 (UTC)[reply]
Major versions should be kept to track development.
First version should be kept.
d1g (talk) 22:20, 9 September 2017 (UTC)[reply]
We should be able to indicate ranges of version numbers, without having to list each version number exhaustively. Generally a version number like "10+" is enough for an open-ended range, or "10 - 12" for a closed range (which usually includes subversions of version 12 for the upper bound, like "12.1", Otherwise we have to use "<= 12", another solution being to indicate "10 - 12*" to include also subversions for the upper bound, in which case "10 - 12" would set the upper bound to "12" included in the range, but "12.1" excluded)
See the remark below about the need to specify multiple versions (this could deprecate the use of "edition" properties, given that each version or set of versions or version ranges can also be restricted by another "type of version" qualifier, indicating "release", "pre-release", ...; versions can also have one or more associated commercial names or numbers to designate the "editions", generally more generic and indicating editions or branches, or supported/subscribed/paid feature sets like "Pro edition", "Home edition"... or commercial/curtesy version names on Windows (95, 98, NT, 2000, XP, Server...), Android (sweetened goodies), or Mac OS (animal names), and many Linux distribs (such as feminine first names on Ubuntu), or heroes/legendary characters (as well there are frequently "code names" used in pre-releases: these code names also have no format, they act like additional tags as well, for example "Redstone 2" for Windows 10).
So "editions" are just to be treated as optional additional "tags" (without any required format, just like brand names) qualifying a precise version number or ranges of version numbers. : A software "edition" is in fact an assembly of multiple software components in a supported "features set", each component having its own version number (in many opensource projects, version numbers evolve constantly and unpredictably at any time; what open source project do is that they designate some branches with "milestone names", also used as qualifying "tags", with unlimited number of tags within the evolution of the software suite). Verdy p (talk) 02:40, 3 November 2018 (UTC)[reply]

Document versions[edit]

Can this be generalized to just "version" to allow for document versions? This is quite common with technical specifications, e.g., .ZIP File Format Specification, version 6.3.4 (Q26211547) is version 6.3.4 of ZIP (Q136218) (currently it seems to be abusing edition number (P393)) or Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220) is version 2.0 of Creative Commons Attribution-ShareAlike (Q6905942) (currently abusing this property unless this is generalized to encompass this usage). 50.53.1.33 21:19, 26 September 2016 (UTC)[reply]

  •  Support. Specifying the version for the standards is quite common practice both in Wikipedia and in Wikidata. We should rename the label to "version" (as already done in many languages) and expand the scope to documents. —putnik 22:21, 2 April 2018 (UTC)[reply]
  •  Support. This is allowed now for "data sets" (which include "files", in any format including "documents", but also "databases"), just like it was allowed for "file formats". Note that "data sets" could be as well treated as subclasses of "software components", which were already allowed (but data sets are not necessarily numeric and computerized). What is missing is to allow versions to "technical specifications" (including "standards", like Unicode, or ISO standards which are versioned by part number/year of publication); there's also a use of version numbers for books (but this is better covered by the "edition" property, even if now many books are also available online as files, i.e. datasets). This causes problems for "documents" because books are subclasses of documents, and documents are not necessarily computerized in a numeric format (the numeric version is most often derived as a non-unique facsimile, but this is not the original book itself). There are some uses of versions for other non-numeric kinds of intellectual or artistic works (I'm not sure that books or other published works can be assimilated as subclasses of "datasets"). There remains some exotic uses of version numbers for organizations that use them as part of their branding and communication (we've seen various exotic examples of "organization 2.0", for example sport clubs). Verdy p (talk) 10:36, 12 November 2018 (UTC)[reply]

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Automatic updates by Github-wiki-bot[edit]

User:Github-wiki-bot automatically extracts stable releases and the release dates of Software from GitHub. – Simon04 (talk) 12:15, 4 August 2017 (UTC)[reply]

Property constraints regex may be wrong[edit]

Please check Linux-libre (Q665683) to see how it is conflicting with real data. NMaia (talk) 11:51, 23 March 2018 (UTC)[reply]

This is solved. Verdy p (talk) 10:51, 12 November 2018 (UTC)[reply]

How do I specifiy and later as in[edit]

Version requirement, e.g. version 1.23+ for Property:P1547? --[[kgh]] (talk) 23:28, 4 April 2018 (UTC)[reply]

This is solved now (see below comments about ranges and the new comma-separated list of versions/ranges) Verdy p (talk) 10:52, 12 November 2018 (UTC)[reply]

Adding version URL for software[edit]

Lets say I'm adding a version for this game data:

https://starbounder.org/Version_1.3.3

The constrains for "software version" doesn't allow me to add the URL in the version number so it's easy to access the changes made in that specific version. Which is easily accessible with the link I gave before.

Can we add the "URL" category to the version software constrains?

As a workaround I'll be using "download link" but it's not entirely true as the link isn't that. --Frenchiveruti (talk) 16:22, 12 June 2018 (UTC)[reply]

Just add a qualifier to the property giving the version number, in order to specify separately a download URL for that version. The allowed qualifier for it is specified above! Verdy p (talk) 11:27, 12 November 2018 (UTC)[reply]
Note: URLs/URIs are not parsable, they are completely opaque, have no defined syntax beside the generic URL format, and so they don't necessarily contain the version number or software that they are related to. As well the same version number will frequently have multiple download URLs (which may be specified as additional qualifiers), meaning that these URLs cannot be used as distinctive identifiers: version numbers are suitable in "URNs", but definitely not as general URLs/URIs, they are indepedendant of the effective location(s), not just at specific URLs/URIs on the web, where a software/dataset/component may be found. Verdy p (talk) 11:34, 12 November 2018 (UTC)[reply]

Exact version numbers[edit]

Until now it was only possible to specify an exact version number. But many softwares are in fact described in ranges of version numbers for compatibility. so the initial words (allowed in the value even if they are not translatable easily) can now also include classic mathematical operators: "<", "<=", "!=", ">=", ">", as well as "≤", "≠", "≥". There's no need of "=" which is implicit. A software may specify multiple versions: but I'm not sure how they can combine, unless we use a leading word ("and", "or") or operator ("&" "|"): this may be needed to specify multiple ranges. The alternative would be to allow separators like ", " for multiple version numbers (each one match with "="), but for version ranges it is not possible ("-" is already used in single version numbers), unless we also allow ".." or " - ". For example:

  • "5 - 6" or "5 .. 6" means all versions from "5*" to "6*
    if we split it into multiple properties: ">= 5", "& <= 6"
  • "10 - 12, 14+" means versions from "10*" to "12*" or "14*" and higher
    if we split it into multiple properties: ">= 10", "& <= 12", "| >= 14"; but the problem is that order of properties is not necessary stable in Wikidata (this is fine to split "or", i.e. unions of conditions, but then it is not for "and", i.e. conjonctions of conditions, due to the different associativity).

So I suggest deciding which separator we could use within a single property value, to mean a conjonction of conditions ("X and Y"):

  • I propose to specify ".." or " - " (or possibly using a long en dash " – ", still with surrounding spaces to avoid confusion with hyphens used without spaces within version numbers) for common ranges of version numbers. I think that ".." (possibly with surrounding spaces, but this is not required) causes less confusion for readers.
  • Also I propose deprecating the leading words allowed in the value (which are not internationalisable in this property, and cause various problems with Bidi, for example with Arabic or Hebrew words) in favor of mathematical operators (plus some separators like the comma for lists of values, or just using multiple separate properties, i.e. one for each value or range of values).
  • As well the semantics of ">= number" (or "number+") is clear, but the semantics of "<= number" should include match not just "number" but also all "number.subversion".
  • That's why "<" is proposed to avoid the ambiguity which exists with closed ranges like "10 - 12", which should also be equivalent to ">= 10" and "< 13" (and not "<= 12"), or with "- 12" (equivalent to "< 13" and not to "<= 12").
  • As well, the semantics of "!= 12" with software version numbers is {"< 12", "or >= 13"} (but not "> 12").
    Note: "!= 12" is semantically equivalent to "< 12, >= 13", or to "< 12, 13+" (but not "< 12, > 12" like in mathematical numbers, even if it may seem counter-intuitive).

This an open question: How do we compare (and order) version numbers with ranges that specify an upper bound?

  • Allowing the comma separator (as an equivalent for saying "or") cause no semantic problem at all: "10,11,14" means that the version number must be exactly "10", or "11", or "14".
  • There's no ambiguity problem when the range is open-ended (with no upper bound), as in "10, 12+".
  • The problem starts when we specify ranges (in the comma-separated list or in a single property specifying a single range), and a range has an upper bound, as in "10, 12 - 14" (the problem is on the interpretation of "14" which should be "< 15", but not "<= 14")
    Solution: "12 - 14" means ">=12" and "<=14" (the upper bound is exact), but "12 - 14*" means ">=12" and "<= 14*", i.e. the same as ">= 12" and "< 15" (upper bound is more fuzzy, "*" implies a prefix notation that allows including subversions) :
  • The interpretation of "12+" means ">= 12" and includes "12", "12.1", "12 Alpha2", "13" (the "+" really means open-ended)
  • The interpretation of "12*" means ">= 12", and "<13" and includes "12", "12.1", "12 Alpha2", but not "13" (the "*" means that the initial prefix before must match exactly, it's not open-ended). So "Windows 8*" would match "Windows 8" or "Windows 8.1" but not "Windows 10", while "Windows 8+" would match the three).

-- Verdy p (talk) 00:03, 3 November 2018 (UTC)[reply]

Here is a version of the regexp with additional newlines, whitespaces, and indentation for readability (non-significant here, must be removed in the final properties):
 (?:                                  (# initial labels: not captured )
   [-A-Za-z_]* (?: \s [-A-Za-z_]* )*
 )
 (?:                                  (# this matches one version number and attached labels, possibly half-open )
   ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# optional version comparator: capture 1 )
   \s?
   (                                    (# main version number: capture 2 )
     \d+ (?: \.\d+ )*
     [-.:\s]? (?:                         (# optional build number )
       [A-Za-z_]\w* (?: [-.:\s]\w+ )*
     )?
   )
   \s?
   ( [*+] )?                            (# optional notation for half-open ranges: capture 3 )
   (?:                                  (# optional descriptive labels in parentheses: not captured )
     \s? \( \w+ (?: [-,.:;\s]\w+ )* \)
   )*
 |                                    (# this matches a closed range of version numbers and attached labels )
   (                                    (# main version number: capture 4 )
     \d+ (?: \.\d+ )*
     [-.:\s]? (?:                         (# optional build number )
       [A-Za-z_]\w* (?: [-.:\s]\w+ )*
     )?
   )
   (?:                                  (# optional descriptive labels in parentheses: not captured )
     \s? \( \w+ (?: [-,.:;\s]\w+ )* \)
   )*
   \s (?: \.\. | [-–] ) \s              (# closed range separator, between spaces )
   (                                    (# main version number: capture 5 )
     \d+ (?: \.\d+ )*
     [-.:\s]? (?:                         (# optional build number )
       [A-Za-z_]\w* (?: [-.:\s]\w+ )*
     )?
   )
   (?:                                  (# optional descriptive labels in parentheses: not captured )
     \s? \( \w+ (?: [-,.:;\s]\w+ )* \)
   )*
 )
It's hard to fit in the 400-characters limit of a property value, so we cannot indicated a list of (versions or version ranges)... unless the installed version of PCRE supports "subroutines" (i.e. identical subrexps to which we give a short alias name and then reuse, which could reduce the total length).
-- Verdy p (talk) 21:34, 6 November 2018 (UTC)[reply]
In full agreement with you on this. Looks like the current regex is broken and needs reworking, however. Adelsheim (talk) 22:10, 7 November 2018 (UTC)[reply]
You don't suggest anything. I asked: can we use PCRE "subroutines" to reduce the 3 identical long lines above to a single one assigned to identier reusable in the 2 other occurences?
If I use "PCRE 5.1 subroutines" (see https://www.regular-expressions.info/subroutine.html or https://www.pcre.org/original/doc/html/pcrepattern.html#SEC23), and make the long subpattern into a subroutine (named "v" here), then this compacts to:
 (?:                                  (# initial labels: not captured )
   [-A-Za-z_]* (?: \s [-A-Za-z_]* )*
 )
 (?:                                  (# this matches one version number and attached labels, possibly half-open )
   ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# version comparator: capture 1 )
   \s?
   (?<v>                                (# this subroutine matches one version number and attached labels )
     \d+ (?: \.\d+ )*                     (# main version number: capture 2 )
     [-.:\s]? (?:                           (# optional build number )
       [A-Za-z]\w+ (?: [-.:\s]\w+ )*
     )?
     (?:                                 (# optional descriptive labels in parentheses: not captured )
       \s? \( \w+ (?: [-,.:;\s]\w+ )* \)
     )*
   )
   ( [*+] )?                            (# optional notation for half-open ranges: capture 3 )
 |                                    (# this matches a closed range of version numbers and attached labels )
   (?&v)                                (# call subroutine to match the starting version number and attached labels )
   \s (?: \.\. | [-–] ) \s              (# closed range separator, between spaces )
   (?&v)                                (# call subroutine to match the ending version number and attached labels )
 )
This is much shorter! Note: a "subroutine" call (by name, or by absolute or relative number) is not a "backreference" to a "capture" because each "subroutine" can match distinct values (using the same subpattern defined in the subroutine) and because the value matched by the subroutine is not captured like normal parentheses: the call of a defined subroutine, or the definition of a subroutine creates only a non-capturing group. Also a PCRE subroutine never backtracks (unlike what Perl permits with its named backreferences, allowing Perl to match palindromes that PCRE cannot).
Note that (?: ... ) is also a non-capturing group: this saves memory and accelerates the matching for backtracking, it is more efficient than ( ... ) notably for repeated subgroups, but also for alternatives. And (?# ... ) is for non-significant comments (that are not matching or capturing anything).
-- Verdy p (talk) 04:48, 10 November 2018 (UTC)[reply]
I tested with subroutines: this works! This allows to specify lists of versions (by naming "r" the top level of parentheses above to form a list of version ranges) using the "PCRE 5.1" syntax for subroutines (i.e. defining them with (?<name> regexp) which performs a submatch, then reusing it with (?&name); note that the syntax for subroutines in regexps is a bit different in Perl and other regexp engines, and older versions of regexp engines may not have support for subroutines) :
 (?<r>                                (# this subroutine matches one version or range )
   (?:                                  (# initial labels: not captured )
     [-A-Za-z_]* (?: \s [-A-Za-z_]* )*
   )
   (?:                                  (# this matches one version number and attached labels, possibly half-open )
     ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# version comparator: capture 1 )
     \s?
     (?<v>                                (# this subroutine matches one version number and attached labels )
       \d+ (?: \.\d+ )*                     (# main version number: capture 2 )
       [-.:\s]? (?:                           (# optional build number )
         [A-Za-z]\w+ (?: [-.:\s]\w+ )*
       )?
       (?:                                 (# optional descriptive labels in parentheses: not captured )
         \s? \( \w+ (?: [-,.:;\s]\w+ )* \)
       )*
     )
     ( [*+] )?                            (# optional notation for half-open ranges : capture 3 )
   |                                    (# this matches a closed range of version numbers and attached labels )
     (?&v)                                (# call subroutine to match the starting version number and attached labels )
     \s (?: \.\. | [-–] ) \s              (# closed range separator, between spaces )
     (?&v)                                (# call subroutine to match the ending version number and attached labels )
   )
 )(?: \s*,\s* (?&r) )*                (# comma-separated list for other versions or ranges )
This now works with a comma-separated list of version numbers version ranges like for supported versions of Windows: "3.0, 3.1*, 95, 98, 98SE, XP, Vista, 7, 8, 8.1, 10, 11".
I just wonder if the initial words (before the comma-separated list) need to be repeated as "r" members of the list, or are implicit prefixes for all of them, so we can add "NT 4, Server 2000" in the list...).
-- Verdy p (talk) 05:11, 10 November 2018 (UTC)[reply]
Once compacted on one line, it becomes:
(?<r>(?:[-A-Za-z_]*(?:\s[-A-Za-z_]*)*)(?:([=≤≠≥]|[<][=>]?|[>]=?|!=)?\s?(?<v>\d+(?:\.\d+)*[-.:\s]?(?:[A-Za-z]\w+(?:[-.:\s]\w+)*)?(?:\s?\(\w+(?:[-,.:;\s]\w+)*\))*)([*+])?|(?&v)\s(?:\.\.|[-–])\s(?&v)))(?:\s*,\s*(?&r))*
Note: there are other labeling schemes supported after the main version number (e.g. other keywords than just "build", complex notations of builds with dots/hyphens, and dates), now the regexp is also case-insensitive. I added embedded comments in the expanded PCRE syntax above (these comments and whitespaces are not needed in the property value: however this page better documents how the regexp is built).
-- Verdy p (talk) 15:08, 22 May 2020 (UTC)[reply]
I have applied some tweaks to the regex:
  • removed two pairs of useless grouping parentheses
  • replaced non-capturing (?:...) with regular (...), for the sake of readability
  • added a \s? to support values such as « 1.5.3 beta » and « 1.4 beta 6 » (encountered on software foobar2000)
As a reminder, the regex is present two times on the page: Property:P348#P1793 and Property:P348#P2302.
Ping Verdy p :)
-- Od1n (talk) 04:13, 9 March 2022 (UTC)[reply]
Also note the occurrences of \w seems to be meant here for "letter", whereas this character class actually means [a-zA-Z0-9_]. As it matches the digits as well, this leads to various false-positives (or to say it differently, it makes the regex pass on values that wouldn't pass otherwise because of issues / missing support in the regex).
However, replacing all the various occurrences of \w with a-zA-Z would make the regex significantly less readable (try it!), and replacing [\d\w] with the technically equivalent [\w] would make us lose some "meaning" in the regex.
-- Od1n (talk) 05:28, 9 March 2022 (UTC)[reply]
You're right, [\w] (for "word characters") also matches [\d], so [\d\w] can be reduced to just [\w]. However, this does not change the functionality or "meaning". I used [\w] just instead of [A-Za-z], because there are some use cases for non-Latin letters (e.g. Greek letters like alpha), or letters with diacritics (like "bêta" or "préliminaire", or some Asian variants) in non-English projects (however [\w] is not necessarily restricted to ASCII only, if regexps have Unicode support). I just hesitated to use Unicode classes (notably those defined for "identifier start character" and "identifier character", such as those used in Javascript, which allows non-ASCII identifiers (including "Roman digits" encoded as variants of Latin letters but handled like numbers or digits). Verdy p (talk) 16:26, 9 March 2022 (UTC)[reply]
Some notes about "shorthand" character classes uin several regexp engines: https://www.regular-expressions.info/shorthand.html (for now it seems that common engines just limit themselves to ASCII).
-- Verdy p (talk) 16:32, 9 March 2022 (UTC)[reply]
Note: the edit to replace non-capturing groups (?:...) by capturing groups (...) has a significant performance impact.
Readability is not an issue in the actual property which is very compacted (the regexp is explained in this page where it is readable, indented, commented inside, and described in this section.
As well there were NO "useless" grouping parentheses, but "litteral" parentheses that must be matched exactly with \(...\),
And there are real capturing groups for significant part (needed for tests, as well as for use to get matched parts).
-- Verdy p (talk) 16:38, 9 March 2022 (UTC)[reply]

Point of time as qualifier[edit]

It is a bit messy to recommend use both publication date (P577) and point in time (P585). I suggest to recommend only more precise and clear publication date (P577) and thus delete point in time (P585) from allowed qualifiers constraint (Q21510851) (and convert point in time (P585) to publication date (P577) by bot).--Jklamo (talk) 09:16, 12 February 2019 (UTC)[reply]

Please re-create this property as item property[edit]

Because software versions should also have their items, not just strings. --117.13.95.116 06:02, 2 April 2019 (UTC)[reply]

+1 but we should indeed wait for Wikidata:Requests_for_comment/how_to_manage_software_versions consensus. --Liuxinyu970226 (talk) 11:03, 2 April 2019 (UTC)[reply]
It depends on! Some software versions are not worth to record each with its item, some are. We need both variants-- JakobVoss (talk) 20:30, 7 November 2019 (UTC)[reply]

Proposal: Clarify usage and generalize[edit]

Proposals[edit]

This property seems to be intended, from the examples, solely to indicate what versions of a specific item exists. So for example, correct usage would be Mozilla Firefox (Q698)software version identifier (P348)3.6. However it is also used quite often as Firefox 3.6 (Q2615631)software version identifier (P348)3.6, even though it seems this is not what was intended.

There is no property proposal I am aware of so I think we need to figure out what we want from this property, but I think cannot be for Firefox 3.6 (Q2615631)software version identifier (P348)3.6 and for Mozilla Firefox (Q698)software version identifier (P348)3.6, and I would say it should only be for Mozilla Firefox (Q698)software version identifier (P348)3.6.

I propose:

  1. We generalize the property to not just be for software
  2. We reaffirm that this property is to be used on items to indicate that the item has a version with the identifier (e.g. Mozilla Firefox (Q698)software version identifier (P348)3.6) and NOT as Firefox 3.6 (Q2615631)software version identifier (P348)3.6.
  3. We change the label to "has version with identifier".
  4. We add usage instructions to make it clear how this should be used (i.e. not on version items but on items with versions)
  5. We constrain the property as best as possible to only allow Mozilla Firefox (Q698)software version identifier (P348)3.6) and NOT allow Firefox 3.6 (Q2615631)software version identifier (P348)3.6.

@putnik, Verdy p: WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Iwan.Aucamp (talk) 13:58, 22 May 2020 (UTC)[reply]

@Iwan.Aucamp: don't spam multiple topics (seen already above). Your proposal here has nothing to do with the property constraint. You just want to restrict the use of this property for specific items created for "specific" versions, specifying the version as part of their label (so not parsable at all as it will get translated randomly): it's safer even in this case to specify a property for the version (or version range using the extended regexp syntax that supports it, and that I explained above, using simple ranges with " .. " or " - " or using "*" for matching all subversions with an upper bound excluded on the parent version, or using comparators that I also explained).
There are also other way to specify specific types of versions that an item may need to reference (e.g. an item may be created for adding new additional features of a software, or removing them, or for indicating deprecation or removal of support, or for adding specific security issues documented). But most software packages/products have a generic item listing its versions just by its list of version numbers (and some qualifiers when needed to distinguish them), and this works for almost all software packages except for specific branches for specific uses, with an independent life cycle even if it originated from a base branch, and where it is not known if these branches will ever be reintegrated into the main branch or will support"backporting" (e.g. security fixes applied in the main branch and only the few other supported branches). When the software is opensourced, generally all branches with their independent lifecycle are just a new kind of software which remains maintained by the community and not requiring any official support from the organization or developer building the main branch (and possibly evaluate the separate development of forked branches).
So I don't understand why you don't want items created for some version ranges to have their own version identifiers as properties. For me it makes no sense and this proposal is just not describing what happens in the real computing industry, that need, use, and deploy various branches of the same base software with their own features added or removed: you proposal is just to limit these possibilities, removing an essential freedom, as if all sofwares were unbreakable "bricks" without many components and various dependencies and possibly incompatibilies between optional or required features. When these incompabilities are with a "core" component, the branch can exclude some of them and resolve the incompatibilities in a different way, creating a new software with its own cycle even if it's part of the same "family". As well there are tons of abandoned branches everywhere, but that are kept as is as long as they work for the effective features that are needed in them. Verdy p (talk) 02:24, 9 September 2020 (UTC)[reply]
@Verdy p: I have no problem with item pertaining to specific versions such as Firefox 3.6 (Q2615631) having properties on them specifying their version. What I have a problem with is that this property is used both to indicate: (A) that an item has a version with the given identifier even though the item itself does not pertain to that version (e.g. Mozilla Firefox (Q698)software version identifier (P348)3.6) and (B) that an item pertains to a version with a given identifier (Firefox 3.6 (Q2615631)software version identifier (P348)3.6). I think a better property for use to indicate that an item pertains to a given version would be edition number (P393), thus I would suggest that Firefox 3.6 (Q2615631)software version identifier (P348)3.6 be replaced with Firefox 3.6 (Q2615631)edition number (P393)3.6.
Following from this, if we go with what I propose .ZIP File Format Specification, version 6.3.4 (Q26211547)software version identifier (P348)6.3.4 would be an incorrect use of this property and ZIP (Q136218)software version identifier (P348)6.3.4 would be a more correct use of this property (though possibly not entirely correct either}).
Would you prefer this property for both cases (A) and (B), if so just vote accordingly below. I don't think ambiguity between (A) and (B) is beneficial and would prefer we constrain this to one or the other which is why I made the proposal. I think if you can raise phrase your objection with specific statements that should or should not be allowed it will make discussion easier. Iwan.Aucamp (talk) 16:26, 26 September 2020 (UTC)[reply]
I have no real preference, but if you want to absolutely make the dichotomy between instances and classes, I tend to prefer a more generic model where every object is also a class, that can be subdivided as needed. With it, we don't really represent a single version number but a range or selection of "compatible" version numbers which can be more or less precise depending on use.
Basically all software are specified within a range of compatibility specifications. Some specifications will be made later and implementations will be reclassified (subclassed) even if they still respect the initial specification for which there was a single version. This is not exceptional and in fact the most important part of human knowledge follows this paradigm, and trying to always make a dichotomy between classes and instances is not productful: instances are not needed, we just need a hierarchy of classes, even if they (most of them) are singletons (for now,; as we never know the future). The best model I can do is to make only a distinction between classes that can exist as objects for themselves: all their properties are definable, at least those that are necessary to make the class working as a black box (independantty of the subclasses seen as a variety of implementations). We can then create some specific subclasses which are "virtual" which are the only one that cannot be instanciated without specifying additional needed properties to distinguish them. We avoid like this the non-sense of "meta-classes", "meta-metaclasses", by allowing each object-class to have its own know properties, plus may be (only in virtual subclasses) some virtual properties which are not directly "instanciable" and distinguishable (comparable). This is only a hierarchy with two levels, there's no more instances and classes, only classes which are or are not comparable (on which no inference is possible except from the properties inherited from the parent class).
But here is it useful ? The current definition already allows setting a unique value when needed (restricting all derived subversions for which no derivation is then allowed, these are "final" classes). But in most cases, multiple values are possible and almost every version specifies a range of versions and almost all classes are still derivable without needing any duplicate entry for each one of its instances (in fact there are always many for any software that is published somewhere, otherwise it would not be usable by anyone else outside his own specific system for a single usage, for a limited time, a strange thing that would not have any value in Wikidata as it would have a single unmaintained source). As in Wikidata everything is modifiable and can be augmented, my opinion is that "instance of" in Wikidata has almost no use. We just need "subclass of" for everything. This is true notably for versions and does not prohibit creating derived subclasses for specific ranges, if needed to specify specific properties for such more precise subranges of versions. Verdy p (talk) 17:22, 26 September 2020 (UTC)[reply]

Amendments[edit]

Place amendments here ... if you want to vote on an amended version of the proposal.

Discussion[edit]

 Comment this is the place to discuss this proposal - if you want to make an amendment use the amendment space and then people can vote there - if you want to make a different proposal make a different proposal. Iwan.Aucamp (talk) 16:26, 26 September 2020 (UTC)[reply]

earliest date (P1319) and latest date (P1326) in allowed qualifiers constraint (Q21510851)[edit]

Sometimes it is not easy to find when a version was released. ie. I'm checking out Nexuiz (Q1328237) release history and my best reference right now is a page on sourceforge which states when a release file was last modified, with no mailing list announcement associated with the release, ie. 2.5.2. That's why I think those two properties should be allowed. If this is a bad idea how do I deal with uncertain publication dates? LotsofTheories (talk) 07:10, 7 March 2021 (UTC)[reply]

Please split this property to 2 properties: Stable software version identifier and Unstable software version identifier[edit]

This property now has loads of multiple values for each software qualifier. splitting makes this property manageable, scalable and ease the programming side in many wikis. Please consider splitting this property to 2 properties: Stable software version identifier and Unstable software version identifier.اقرأ (talk) 11:56, 4 April 2021 (UTC)[reply]

I disagree: a version number is a version number, whatever its support status (which is an orthogonal/independant property).
Almost all softwares have the same version numbering, and the support status evolves over time (even an unstable version, initially, can finally become stable and supported, and then still stable or not, but no longer supported, or specific to a branch).
If you want to discriminate versions, you need another property (to be used as a qualifier), but items will still need the same version number property (which is an identifier, independant of the software lifecycle, or quality, and also independant of who supports it, something that could also change over time: it may not longer be supported by a company, but supported by others, or still supported under specific contracts, or paid support subscriptions, or legal requirements). Verdy p (talk) 19:25, 9 March 2022 (UTC)[reply]
See also the proposed additional qualifier for "end of life" below. Verdy p (talk) 19:27, 9 March 2022 (UTC)[reply]

end of life date qualifier[edit]

Any thoughts on allowing the usage of discontinued date (P2669) as a qualifier to indicate when support ends for a release? As an example, many Linux distributions release versions with set dates for which that release is no longer supported and will no longer receive security updates. I think that is a useful data point to record. Chuckfinley71 (talk) 19:33, 14 January 2022 (UTC)[reply]

Sounds good to me. —Dexxor (talk) 20:19, 15 January 2022 (UTC)[reply]

property scope constraint property scope constraint (Q53869507) including references as well? 1 use-case presented[edit]

So I used file (Q181820) version 5.39 as a determination method (P459) to determine what file format a specific "tar.gz" of eSpeak NG (Q63169533)(version 1.50) for the Linux (Q388) platform is. The file was "gzip compressed data"(GZIP (Q10287816)) which I put as a qualifier for checksum (P4092) and I used the references field to show how I came to my conclusion that the file is in the "gzip file format". Still I get an error in the references field for this property "The property software version identifier should not be used in this location (as reference)". Am I doing anything wrong? Maskingself (talk) 13:17, 13 March 2022 (UTC)[reply]

@Maskingself: Constraints are hints, not firm restrictions. We don't need to change the constraint for a rare exception like this. Dexxor (talk) 17:31, 14 March 2022 (UTC)[reply]

Restriction format constraint (Q21502404) in property constraint (P2302) should be removed[edit]

Each developer can freely mark the software version. There is no strict global rule. When it comes to software that is over a decade old, there are no rules. Therefore, I propose to remove format constraint (Q21502404) rule. Architekt1024 (talk) 01:07, 14 July 2022 (UTC)[reply]

 Support: The regex produces many false positives, see e.g. aptitude and OpenSSL. If there are some people who actually make use of the constraint violations, we should at least massively simplify the regex to [0-9a-z.-]+ to only catch the most blatant format violations. Dexxor (talk) 04:58, 14 July 2022 (UTC)[reply]
 Support: Some software use things like git-commit hash as part of their version for constantly updating software. Software versioning is only there to keep track of which version comes after another and it can't expressed in a one format for all. Ipr1 (talk) 00:45, 1 March 2024 (UTC)[reply]
 Support: The status quo is not descriptive of what a version identifier is. As has been said above, in reality, there are only a few constraints on what could be a version identifier. Janhrach (talk) 18:14, 5 March 2024 (UTC)[reply]
 Support: I'm also regularly encountering false positives, and the regex is just unmaintainable. You might be interested in a talk above: #Exact version numbers. There are so many different cases we couldn't even use a simple range like [0-9a-z.-]+ as suggested above. Note the regex has already been removed from P1793. Od1n (talk) 07:36, 31 March 2024 (UTC)[reply]

✔️ I have removed the constraint: 2139780732. Note there is also a /.{1,200}/ mandatory constraint (1191891426), which I think is the most specific we can have in practice… Od1n (talk) 00:44, 29 April 2024 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P348&oldid=2139786058"