Talk:Software versioning

Software Versioning - talk page guidelines

In addition to the standard Wikipedia:Talk_page_guidelines:

• Keep all discussion focused on the article page content. Random factual statements are of no use to us. If you are suggesting new content, say so!
• Please use the appropriately titled section below to add comments about specific sections in the article. If you don't find it, please add it.
• Propose a new article section by creating a section title of "Proposed:proposed_title".
• Remember to sign your posts! Add four squiggly (~~~~) characters at the end.

JwD (talk) 01:13, 3 March 2018 (UTC)

Talk page reorg (WIP)

I am moving some old discussion sections into a "Noise from the past" section that we can eventually archive or delete. Trying to get setup for discussions on how to fix the current Software Versioning page, which needs a lot of work. I'll my thoughts on that later. JwD (talk) 20:51, 3 March 2018 (UTC)

Except for content rescued in the next few days, I intend to archive the entire "Noise form the past" section of this page by EOW. JwD (talk) 23:05, 3 March 2018 (UTC)

Old content archived. JwD (talk) 23:32, 21 April 2018 (UTC)

Document purpose, structure, quality

Adding this section to collect discussion on the document in general, that isn't focused on any particular section. JwD (talk) —Preceding undated comment added 19:42, 3 March 2018 (UTC)

Time to edit this talk page?

There seems to be a bunch of content on this talk page that violates WP:TPG, making it quite messy:

• Some anecdotes that, while funny, don't discuss the article:
  • The truth about interpreting Version Numbers
  • New versioning method
• Topics that discuss software versioning itself, rather than the article:
  • Versioning in general
  • version vs revision
  • versioning system != decimal system?
  • Skype
  • 169?
  • Do you know an application that use this schema?
  • Microsoft's build number is actually an encoded date?
  • GloboLinux and octal versioning
  • Calendar based version numbering scheme
• An unsigned ten paragraph essay above the table of contents that seems to be one person's personal reflections on software versioning and, again, doesn't discuss the article itself.

I was going to delete all this stuff, but the guidance at WP:TPG made me a bit skittish about deleting, so I'd like to seek some concensus before doing so. — Preceding unsigned comment added by SixSix (talk • contribs) 15:24, 5 August 2011 (UTC)

Why not just move the offending material to an archive page, as WP:TPG recommends? -- Schapel (talk) 20:04, 5 August 2011 (UTC)

Whatever is decided, I think it needs a cleanup, too. Bujiraso (talk) 15:42, 11 June 2013 (UTC)

Both the talk page and the article need a lot of work! JwD (talk) 00:33, 3 March 2018 (UTC) WIPJwD (talk) 21:33, 3 March 2018 (UTC)

Noise moved into a separate section. We should discuss whether some or all of it should archived or deleted perhaps? JwD (talk) 22:12, 3 March 2018 (UTC)

@JosephDonahue: It should absolutely be archived, some of it's ancient. (Not deleted, WP:TALKCOND is very clear on that: "Archive—don't delete".) Manual cleanup can interfere with archiving, though, which is usually automated. It's generally best to leave things be and let the bots do their job.

(Make no mistake, your efforts were well-intentioned and are very much appreciated — please, please don't take this as any sort of criticism or complaint against you or your efforts. You saw a lot of people talking about a problem, but nobody doing anything, so you stepped in to take action. That's commendable! Wikipedia has a lot of bureaucracy and nebulous structure that's built up over its lifetime, and it can be both confusing and unwelcoming for inexperienced editors whose only real choice is to throw themselves in the deep end with minimal support or assistance. That's an unfortunate reality of how the project operates, and most editors understand because they remember when they were in that very same boat.)

Archiving on Wikipedia Talk pages is one of the many housekeeping functions that can be performed by the small army of bots roaming the system. Over the years, Wikipedians have written those bots to keep up with repetitive tasks, since the system long ago grew too large for human editors to handle all of it. (Keeping up with all the repetitive housekeeping, especially, is a giant chore. Avoidance of those tasks is the prime motivation behind many bots' existence.)

Wikipedia's archive bots work by identifying Talk page sections that have received no updates in whatever period of time is configured as being "old" for discussions on that page, and they shift those sections into the archive. That's why the guidelines at WP:TPG start with a general admonishment against editing existing Talk page discussions, then go into some exceptions to that general rule. (And one of those exceptions is to perform housekeeping and archiving tasks. So, don't worry, you did absolutely nothing wrong here! Again, this isn't an accusation or complaint. I simply want to bring the archiving options and methodology to your attention.) Pointing an archive bot here pre-cleanup would've cleared out most of that noise on the first run. But now that all of those sections have been newly-edited, they'd no longer be targeted. We can still deal with it manually, of course, so it's not a major concern. Just something to be aware of.

Normally I might ask if you wanted to self-revert the page to a state prior to your cleanup, and go forward from there with archiving. But I see that there's been new content added since then, and we're probably too deep in the woods to go back at this point. Better to just press forward. I still think automated archiving makes sense for this page, it clearly receives discussion that needs to be rolled off over time. I'm happy to do the work of establishing Lowercase sigmabot III archiving here. Before doing that, procedure advises that I put the idea up for discussion, and determine the consensus of the group regarding whether archiving should be performed (and under what parameters). So, consider this that proposal, and call for consensus. -- FeRD_NYC (talk) 12:50, 21 April 2018 (UTC)

@FeRD NYC:, any assistance from someone with more wiki-foo than I posses, will always be appreciated. Are you also a subject matter expert here? I did read through a bunch of documentation on the subject and came to the conclusion that I should stir the pot first, to see if anyone was paying any attention. Archiving by age does not seem entirely appropriate, since there are some, IMO, legitimate open issues among them that should be addressed first. I figured if nobody chimed in, I'd just have to archive the older content at some point in the future. I think everything in the 'Noise from the past' section should be archived at this point in time.

Which I am about to do... JwD (talk) 23:33, 21 April 2018 (UTC)

@JosephDonahue: Sorry, just saw this. (It's another one of Wikipedia's "gotchas" that using Template:reply to fails to create a notification if the edit in which it's placed doesn't have a signature included with it, to provide the "sender" side of the notification. Even if subsequent edits or bot visits sign the comment. There's even a whole help page containing a (long, stupid) procedure just for dealing with that utterly brain-dead nonsense.)

To answer your questions, I'm not a topic expert by any stretch of the imagination, no. I think the current archiving looks sensible, it definitely helps pare down the page. Auto-archiving can be done with any idle period (even "older than 2 years", or "...5 years", if that was deemed the appropriate window of time), though it's true it's more typically used on talk pages that receive heavier traffic, not simply ones where a decade's worth of cruft has accumulated. If someone (i.e. you) is willing to keep up manual archiving, in order to separate the outdated from the simply old in deciding what to roll off, then that seems perfectly reasonable to me. Best of luck! -- FeRD_NYC (talk) 17:49, 5 May 2018 (UTC)

Future Directions

The table is set for discussions on the next steps towards improving the quality of the Software versioning page. There's some things we need to agree on here so that future contributors will know what to add where and whether it's appropriate for this page at all.

1. What distinguishes this page from the Version control page?
2. How does this page tie in with other related pages (All pages with titles containing version)?
3. What core top-level section topics are absolutely necessary?
   1. What sub-headers are essential to each of those?
4. Should we have a table of schemes and organizations/products that use those schemes, rather than adding random content that "X does Y"?
5. Is a string like "Windows 10" really a version of anything?
   1. IOW: Can we please separate product histories, trademarks and branding, from that which is an actual version of something? For instance, there have been literally thousands of versions of the Windows 10 already.
6. Should we mention software publishing channels and packaging tools? Aren't those the opposite book-end from revision control systems?
7. Should we promote addition of versioning standards summaries and links to official standards sites over descriptions of the ever increasing numbers of one-offs that come along?

Any more ideas?

JwD (talk) 22:52, 3 March 2018 (UTC)

Versioning in general

There are actually two things that are versioned in general:

• Some atomic entity (in CVS/SVN/CMS/... it is the file).
• A collection of atomic entities.

Hence, we should disinguish between the two. Also, for one purpose, a collection may be atomic (i.e. the marketing division @ Microsoft sees the entire operating system as an atomic whole, and thus 'versions' it as Windows XP 2000). Then for the purpose of some developers at Microsoft a small set of files comprices the socket library (which then also gets its version). Finally, Mr. BigProgrammer (lots of pizza), is *the* editor of sock.c. This file is also individually versioned in some versioning system.

My point being: It is not possible to talk generally about versioning in other ways than just specify what is versioned, and the scheme of the numbering system: My car is in its next version after it has had a maintenance service; it would be nice if that version was a higher number than the previous one so that it is easy to talk about it and track it. Since it it my car, I'll adopt a numbering scheme, I think ;-)

Versioned things are:

• A description of things that comprices an atom in our version database. Being an atom, all actions performed on it should be atomic (with regards to the versioning database).
• A set of actions to take to make the next version of the atom.

For version control systems, the description of the atom is the file (and the folder for Subversion). The actions to take are well defined for files and folders by the tool in use, such as 'check-in', 'check-out', 'commit' etc.

What I'm missing from the versioning systems is an easy way to define a collection of atoms (to create a new kind of atom) and a way to treat such a collection exactly the same way as we treat files.

Hawkis 15:44, 9 August 2006 (UTC)

Proposed: History of versioning

If anybody can track down some history of versioning schemes, it would be interesting to know. For example, back in the good old days, "everybody knew" that version numbers were just a series of integers separated by periods. (Not decimal points!) I know from personal experience that this convention pre-dates the mid-1970's, but where did it come from? As more people came in to the computing field without significant contact with their predecessors, there was an explosion of interpretations of the meaning of version numbers. (Such as the idea that they are floating point numbers, adding letters, leading zeros, etc.)

I don't have any cites for any of this, but I'm thinking the origin of version numbers is probably somewhere in the late 50's / early 60's, like so much other fundamental computer technology. 130.167.237.185 (talk) 19:47, 14 April 2014 (UTC)

This is a good idea. I happen to know from experience that the earliest software versioning schemes were simply the application of existing schemes used by the organization to track their circuit board revisions. The basic concept however goes all the way back to the early days of the printing press. It would be good to have references to point to however. I modified the section title to reflect that this is a proposed article section. JwD (talk) 21:56, 3 March 2018 (UTC)

Change significance

"If changes are made between, say, 1.3rc4 (a release candidate) and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all.[clarification needed]"

This doesn't make sense at all. Doesn't seem to be a complete sentence. — Preceding unsigned comment added by 2014-08-10T08:09:40‎

I agree, the whole section needs an overhaul, and that first sentence in the third paragraph is patently false. JwD (talk) 01:49, 3 March 2018 (UTC)

Reworked. JwD (talk) 20:36, 24 April 2018 (UTC)

It's a complete sentence; my grammatical skills aren't that bad. :-) It addresses the *semantics* of the shape of a version number, as those are understood by users. Any given version of a package which is released with a version number that's been used as part of an alpha-beta-gamma-releasecandidate sequence is expected to have been tested to the level of whatever test-release preceded the final. If everyone thought 1.3rc4 was ok, after it fixed 1.3rc3's problems, then *1.3rc4 has to be the exact codebase that's released as 1.3*. If *any changes are made*, then users can't have any confidence that those changes didn't break things, after the positive comments made about 1.3rc4 -- a 1.3rc5 Must Be Tested to provide that confidence. *That's* what I'm talking about here. I'll see if I can expand it as to make it clearer; I was trying to acknowledge observed standard practice, without taking over that entire section of the article...
--Baylink (talk) 03:59, 7 January 2019 (UTC)

SemVer, PEP 440

I think versioning specifications like SemVer or PEP 440 should at least be mentioned in the article. -- 62.96.157.13 (talk) 12:04, 4 April 2018 (UTC)

SemVer is currently mentioned twice in the document. I added a brief outline to the "Change significance" section. JwD (talk) 20:40, 24 April 2018 (UTC)

Added Python to Schemes with a reference to PEP-440.

Proposed merge with Software release train

scope and size better sited at target Widefox; talk 12:12, 23 April 2019 (UTC)

Proposal: Split "Schemes" into separate article

The "Schemes" section is fairly long. I wonder if moving it to its own page could help make it and "Software versioning" as a whole easier to read? Llama Linguist (talk) 02:37, 3 January 2022 (UTC)

Citation 10 no longer available

"Daemonite: The science of version numbering". is no longer available at blog.daemon.com.au. I suggest pointing to the waybackmachine: The science of version numbering No-bug404 (talk) 14:45, 15 November 2022 (UTC)

Needs an Introduction

While this page covers the topic of *sofware release numbering*, it doesn't ask *why* version numbers are chosen.

It needs to add an introduction, with key reasons being

Technical: software updates may be incompatible or introduce bugs as well as features. Knowing which version is being used helps identify what is available/gone wrong. They are also essential for issue tracking.

There is an expectation that minor versions are backwards compatible. Big version upgrades tend not to make such strong guarantees. (+point to DL Parnas here)

Marketing: big version numbers changes are often used as a way of highlighting that a new version is significant and upgrading is worth doing "windows 95", "windows 98", compared with "windows 95 OSR 2" (OEM Service Release 2) which was a maintenance package for the OEMs, not end users.

There are also some special cases, where major changes don't get major version increments

• Windows 3.11 which was a tangible update on windows 3.1, but which microsoft kept at 3.11 because of some license with novell meant they'd have had to re-license the netware client if they did a bigger change.
• Some of the windows 10 upgrades "2022H2", which may be designed to not scare you away
• Open source, some projects release big changes in minor point releases so they can meet their commitments to maintain branch X.Y without adding another branch to maintain. I have some examples, but wouldn't want to name them unless someone has references they can cite.

Anyone want to take this up?

Names vs. numbers

Mention Android along with Debian.

Mention if fun names might seem smart, but require others to have to use lookup tables to determine which version is older.

Also mention e.g., if names get dropped when it become too much of a hassle.

Jidanni (talk) 15:18, 13 December 2023 (UTC)