Property talk:P348

From Wikidata
Jump to navigation Jump to search


software version identifier
numeric or symbolic identifier of version of a software or file format, current and past
DescriptionVersion numbers of versions of the software. Qualify with version type (P548) and point in time (P585).
Representssoftware version (Q20826013)
Data typeString
According to this template: software (Q7397)
According to statements in the property:
software (Q7397), software component (Q20919931), file format (Q235557), programming language (Q9143), data set (Q1172284), website (Q35127), public copyright license (Q7257715), video game (Q7889) and work (Q386724)
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:
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 from Bell Labs (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: sameno label (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)
Proposal discussion[not applicable Proposal discussion]
Current uses11,629
Search for values
[create] Create a translatable help page (preferably in English) for this property to be included here
Format “[\w\s]*(?<r>([<!>]=?|[<=]>|[≤≠≥])?\s*(?<v>\d+(\.\d+)*\w*(\s|-)?([Bb]uild|B|rc|RC|[Aa]lpha|[Bb]eta|[Uu]pdate|RTM|ESR)?(\s|-)?\d*(\s|-)?(\([\w\s]+\d*\))?)([*]|\s*[+])?|(?&v)\s+(-|\.\.)\s+(?&v))(\s*,\s*(?&r))*: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P348#Format, SPARQL, SPARQL (new)
This property is being used by:

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


I report this discussion on the project chat (Wikidata:Project_chat/Archive/2013/04#Property:P348_-_Stable_version_.28software_only.29) regarding the qualifiers properties. --Viscontino talk 08:45, 5 April 2013 (UTC)

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)
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)
✓ Done. John Vandenberg (talk) 02:01, 19 September 2014 (UTC)

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)


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)

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)

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)
So from the last two links I take it the statements are supposed to stay? —DSGalaktos (talk) 22:14, 26 March 2015 (UTC)
Yes :) ·addshore· talk to me! 00:05, 27 March 2015 (UTC)
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)
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)

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)

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)

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)
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)

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)

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)

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)

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 (P747) has a conflicting label. —Galaktos (talk) 10:20, 4 December 2015 (UTC)
Thanks. — Vort (talk) 13:37, 4 December 2015 (UTC)

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)

Some articles have tables of versions, for which Wikidata could be referred to. --AVRS (talk) 21:21, 2 August 2016 (UTC)
Major versions should be kept to track development.
First version should be kept.
d1g (talk) 22:20, 9 September 2017 (UTC)
  • Entries are not deemed to be complete. We don't delete no longer current, but accurate statements. Just set the recent one as preferred. See Help:Ranks.
    --- Jura 08:53, 10 September 2017 (UTC)
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)

Document versions[edit]

Ruud Koot
Daniel Mietchen
Tinker Bell
Jasc PL
Tris T7
Peb Aryan
Pictogram voting comment.svg Notified participants of WikiProject Informatics

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). 21:19, 26 September 2016 (UTC)

  • Symbol support vote.svg 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)
  • Symbol support vote.svg 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)

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)

Property constraints regex may be wrong[edit]

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

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

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)

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)

Adding version URL for software[edit]

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

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)
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)
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)

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)

Here is a version of the regexp with additional newlines and indentation (non-significant here, must be removed):
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)
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)
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 or, and make the long subpattern into a subroutine (named "v" here), then this compacts to:
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).
Verdy p (talk) 04:48, 10 November 2018 (UTC)
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) and 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) :
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, 95, 98, 98SE, 7, 8, 8.1, 10".
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)

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)

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

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

+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)