I have a large personal software library that I have been working on and is currently working on. Currently, its version is 0.1.0.
It is not mature enough to have a major version of 1. I keep modifying the code and introducing incompatible changes that would merit an increase of the major version number. At the same time, some of my other libraries depend on this library and refer to it by the version number.
If I introduce incompatible changes and don't want to increase the major version from 0 to 1, how should I increment my version number?
The SemVer website is not very clear on that, it just says:
Major version zero (0.y.z) is for initial development. Anything may
change at any time. The public API should not be considered stable.
Does "anything may change at any time mean" that an exception is made for a major version of 0 and that I can change the y and z numbers however I like?
For instance, if my version is 0.1.0 and I introduce an incompatible change, could the new version with that change be 0.2.0?
What others say
On this site it says:
In fact, the SemVer spec defines that anything starting with “0.”
doesn’t have to apply any of the SemVer rules.
Another site also seems to suggest that it is OK to increase the minor version when the major version is 0 and incompatible changes are added:
So you just continue through the 0.x.y range, incrementing y for every
backwards-compatible change, and x for every incompatible change.
It's up to you because
If other libraries depend on your software it means that your software has some consumed public APIs and if it has them... Why isn't already at 1.x.x version?
After all... why is so important that your software reaches the 1.0.0 version only once it's stable? It could start with 3.0.0 or 4.0.0 once it reaches a stable version...
Your software isn't mentally decoupled from your bigger project because, in fact, you'll consider it "mature" only when the whole software (made of a lot of smaller libraries) reaches a "mature" version. But from a technical perspective it's already decoupled 😉
It's right that starting from 0 you don't have to strictly adhere with the semver rules
Everything revolves around what is considered "mature". You told that your software isn't mature but what does it mean? That could be improved? That it doesn't cover all the corner cases? That it's not 100% tested?
In the end: if you don't consider it mature continue with the 0.x.y versioning and increase the minor version but your immature software is already consumed by other libraries so it should now reach the 2.0.0 version 😉
I get the logic of MAJOR.MINOR.PATCH and kinda intuitively get what -alpha and -beta mean at the end of a semver number but -rc doesn't ring any bell for me.
Couldn't find a satisfying answer there -> https://semver.org/
The meanings of prerelease and build meta tags in SemVer strings is entirely up to the publisher. Always consult the publisher's documentation before acting on tag content. As #lemieuxster points out however, "rc" is likely an acronym for Release Candidate.
In the absence of publisher documentation, you can not make assumptions about meanings of any prerelease tag. The spec defines precedence based entirely on the tag's ASCII code points and the number of fields: 1.0.0-airdale < 1.0.0-airdale.dog < 1.0.0-boring < 1.0.0-zed. They don't have to have any implied meaning for the sort algorithms to do their job. There's nothing special about "-alpha" unless the publisher documents what it means.
RC means release candidate. A release candidate (RC) version is a beta version likely to be a stable product. Generally, the last two releases may be stable release.
RC stands for release candidate, It is a version of a software program that is still being tested, but is ready to be released. If no major issues are found in the release candidate, then it is released to the public.
RC is made available for "last minute testing" purposes to detect any remaining errors within the program.
On Unix-like systems dynamic shared libraries (.so files) have an SONAME.
It can be extracted for example with:
readelf -a libfoo.so.0.3.2 | grep SONAME -> libfoo.so.0.
The last part is also called the SOVERSION.
That version number marks versions of the library that are binary compatible (ABI).
So when a program links to one version of the library it can also use a later version if the SOVERSION doesn't change.
Libtool has a -version-info mechanism to decide such a SOVERSION with current, revision and age.
The clue is: current is increased also on compatible changes and major = current - age is used on most systems to set the SOVERSION.
However, on BSD (FreeBSD, NetBSD, OpenBSD) the SOVERSION is set to current, which is mentioned in a couple of places like the
suse-wiki,
and I also tested this on the mentioned platforms.
The question is: Why is libtool doing this on BSD?
Why is this considered to be "the way BSD does this"?
That means every compatible change for Linux/Darwin/SunOS is an incompatible change for the BSDs, because the SOVERSION changes.
According to at least one developer who posted on the GNU mailing list, this could be considered a bug:
https://lists.gnu.org/archive/html/bug-libtool/2011-05/msg00007.html
That email is also full of useful references to the library versioning policies to various BSDs, which do appear to contradict libtool's behaviour
I'm somewhat confused on the Linux kernel version numbers. I noticed that many Linux distributions do no use the latest Kernels, in fact I have seen a few using version 2.4. Is there a reason for this? Is there any differences between 2.4, 2.6, 3.2 apart from age? What are the security implications of using an older kernel?
Different kernels have different features and improvements the developers of a distribution take a look at features they are going to support then decide which kernel to use based on the most stable support of that kernel.
It is the decision of the distribution developer which one to use, and they would go with the one they felt comfortable with.
This is a feature of software development its like asking what Java 1.1 and Java 1.7 is and whats the difference is apart from age... the answer is many things.
Most kernels and software will also have a security patch schedule and it is up to the user to keep their systems patched and up to date if you do not then you invite security issues as they are never fixed.
between major releases (e.g. 2.4 and 2.6), new features are introduced and old features are deprecated, eventually making the kernel binary incompatible.
this is important if you depend on some kernel-module that is not part of the mainline kernel (e.g. it is proprietary and the original authors don't provide updated modules; or it is open source (but never made it into the kernel) and nobody is willing to spend time to migrate the code)
also a new major release might change the system behaviour significantly. i remember that when switching from 2.4 to 2.6, many people that needed low latency audio (that's my background, so forgive me) would stay with the old kernel, since the new scheduling algorithms performed worse in some situations.
I hope the below page would help us in understanding the linux version numbering system:
http://www.linfo.org/kernel_version_numbering.html
A snap from http://www.tldp.org/FAQ/Linux-FAQ/kernel.html#linux-versioning
Linux version numbers follow a longstanding tradition. Each version has three numbers, i.e., X.Y.Z. The "X" is only incremented when a really significant change happens, one that makes software written for one version no longer operate correctly on the other. This happens very rarely -- in Linux's history it has happened exactly once.
The "Y" tells you which development "series" you are in. A stable kernel will always have an even number in this position, while a development kernel will always have an odd number.
The "Z" specifies which exact version of the kernel you have, and it is incremented on every release.
There is a human-readable changelog for the Linux Kernel.
Some people take the attitude "if it works - don't change it". So, there are security implications of running an older kernel - but there's also the risk that upgrading may break something.
As kernels improve/change, they might break expectations that held on earlier versions. If a distribution becomes unstable because too many software breaks under the new version of the kernel, the developers might opt to use an earlier version until the software is able to handle the changes in the new kernel.
Typically a binary image may not be portable between kernels where the first or second part of the version number changes. So in order to upgrade from 2.4 to 2.6, a large proportion of libs and executables will need to be upgraded / recompiled too. This can be a particular problem if you use closed source applications/drivers.
Most Linux distributors will back port patches from newer kernel versions depending on the security impact / demand for additional functionality. If you're not able to upgrade your entire system at regular intervals, then you need to find a distribution which explicitly supports a long support cycle with a good history of back porting (e.g. RHEL, SuSE).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I distribute software online, and always wonder if there is a proper way to better define version numbers.
Let's assume A.B.C.D in the answers. When do you increase each of the components?
Do you use any other version number tricks such as D mod 2 == 1 means it is an in house release only?
Do you have beta releases with their own version numbers, or do you have beta releases per version number?
I'm starting to like the Year.Release[.Build] convention that some apps (e.g. Perforce) use. Basically it just says the year in which you release, and the sequence within that year. So 2008.1 would be the first version, and if you released another a months or three later, it would go to 2008.2.
The advantage of this scheme is there is no implied "magnitude" of release, where you get into arguments about whether a feature is major enough to warrant a major version increment or not.
An optional extra is to tag on the build number, but that tends to be for internal purposes only (e.g. added to the EXE/DLL so you can inspect the file and ensure the right build is there).
In my opinion, almost any release number scheme can be made to work more or less sanely. The system I work on uses version numbers such as 11.50.UC3, where the U indicates 32-bit Unix, and the C3 is a minor revision (fix pack) number; other letters are used for other platform types. (I'd not recommend this scheme, but it works.)
There are a few golden rules which have not so far been stated, but which are implicit in what people have discussed.
Do not release the same version twice - once version 1.0.0 is released to anyone, it can never be re-released.
Release numbers should increase monotonically. That is, the code in version 1.0.1 or 1.1.0 or 2.0.0 should always be later than version 1.0.0, 1.0.9, or 1.4.3 (respectively).
Now, in practice, people do have to release fixes for older versions while newer versions are available -- see GCC, for example:
GCC 3.4.6 was released after 4.0.0, 4.1.0 (and AFAICR 4.2.0), but it continues the functionality of GCC 3.4.x rather than adding the extra features added to GCC 4.x.
So, you have to build your version numbering scheme carefully.
One other point which I firmly believe in:
The release version number is unrelated to the CM (VCS) system version numbering, except for trivial programs. Any serious piece of software with more than one main source file will have a version number unrelated to the version of any single file.
With SVN, you could use the SVN version number - but probably wouldn't as it changes too unpredictably.
For the stuff I work with, the version number is a purely political decision.
Incidentally, I know of software that went through releases from version 1.00 through 9.53, but that then changed to 2.80. That was a gross mistake - dictated by marketing. Granted, version 4.x of the software is/was obsolete, so it didn't immediately make for confusion, but version 5.x of the software is still in use and sold, and the revisions have already reached 3.50. I'm very worried about what my code that has to work with both the 5.x (old style) and 5.x (new style) is going to do when the inevitable conflict occurs. I guess I have to hope that they will dilly-dally on changing to 5.x until the old 5.x really is dead -- but I'm not optimistic. I also use an artificial version number, such as 9.60, to represent the 3.50 code, so that I can do sane if VERSION > 900 testing, rather than having to do: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), where I represent version 9.00 by 900. And then there's the significant change introduced in version 3.00.xC3 -- my scheme fails to detect changes at the minor release level...grumble...grumble...
NB: Eric Raymond provides Software Release Practice HOWTO including the (linked) section on naming (numbering) releases.
I usually use D as a build counter (automatic increment by compiler)
I increment C every time a build is released to "public" (not every build is released)
A and B are used as major/minor version number and changed manually.
I think there are two ways to answer this question, and they are not entirely complimentary.
Technical: Increment versions based on technical tasks. Example: D is build number, C is Iteration, B is a minor release, A is a major release. Defining minor and major releases is really subjective, but could be related things like changes to underlying architecture.
Marketing: Increment versions based on how many "new" or "useful" features are being provided to your customers. You may also tie the version numbers to an update policy...Changes to A require the user to purchase an upgrade license, whereas other changes do not.
The bottom line, I think, is finding a model that works for you and your customers. I've seen some cases where even versions are public releases, and odd versions are considered beta, or dev releases. I've seen some products which ignore C and D all together.
Then there is the example from Micrsoft, where the only rational explanation to the version numbers for the .Net Framework is that Marketing was involved.
Our policy:
A - Significant (> 25%) changes or
additions in functionality or
interface.
B - small changes or
additions in functionality or
interface.
C - minor changes that
break the interface.
D - fixes to a
build that do not change the
interface.
People tend to want to make this much harder than it really needs to be. If your product has only a single long-lived branch, just name successive versions by their build number. If you've got some kind of "minor bug fixes are free, but you have to pay for major new versions", then use 1.0, 1.1 ... 1.n, 2.0, 2.1... etc.
If you can't immediately figure out what the A,B,C, and D in your example are, then you obviously don't need them.
The only use I have ever made of the version number was so that a customer could tell me they're using version 2.5.1.0 or whatever.
My only rule is designed to minimize mistakes in reporting that number: all four numbers have to be 1 digit only.
1.1.2.3
is ok, but
1.0.1.23
is not. Customers are likely to report both numbers (verbally, at least) as "one-one-two-three".
Auto-incrementing build numbers often results in version numbers like
1.0.1.12537
which doesn't really help, either.
A good and non-technical scheme just uses the build date in this format:
YYYY.MM.DD.BuildNumber
Where BuildNumber is either a continuous number (changelist) or just starts over at 1 each day.
Examples: 2008.03.24.1 or 2008.03.24.14503
This is mainly for internal releases, public releases would see the version printed as 2008.03 if you don't release more often than once a month. Maintenance releases get flagged as 2008.03a 2008.03b and so on. They should rarely go past "c" but if it does it's a good indicator you need better QA and/or testing procedures.
Version fields that are commonly seen by the user should be printed in a friendly "March 2008" format, reserve the more technical info in the About dialog or log files.
Biggest disadvantage: just compiling the same code on another day might change the version number. But you can avoid this by using the version control changelist as last number and checking against that to determine if the date needs to be changed as well.
In the github world, it has become popular to follow Tom Preston-Werner's "semver" spec for version numbers.
From http://semver.org/ :
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version
when you add functionality in a backwards-compatible manner, and PATCH
version when you make backwards-compatible bug fixes. Additional
labels for pre-release and build metadata are available as extensions
to the MAJOR.MINOR.PATCH format.
I use V.R.M e.g. 2.5.1
V (version) changes are a major rewrite
R (revision) changes are significant new features or bug fixes
M (modification) changes are minor bux fixes (typos, etc)
I sometimes use an SVN commit number on the end too.
Its all really subjective at the end of the day and simply up to yourself/your team.
Just take a look at all the answers already - all very different.
Personally I use Major.Minor.*.* - Where Visual Studio fills in the revison/build number automatically. This is used where I work too.
I like Year.Month.Day. So, v2009.6.8 would be the "version" of this post. It is impossible to duplicate (reasonably) and it very clear when something is a newer release. You could also drop the decimals and make it v20090608.
In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
Major version numbers can break all three forms.
I wrote more about the rationale here.
For in-house development, we use the following format.
[Program #] . [Year] . [Month] . [Release # of this app within the month]
For example, if I'm releasing application # 15 today, and it's the third update this month, then my version # will be
15.2008.9.3
It's totally non-standard, but it is useful for us.
For the past six major versions, we've used M.0.m.b where M is the major version, m is the minor version, and b is the build number. So released versions included 6.0.2, 7.0.1, ..., up to 11.0.0. Don't ask why the second number is always 0; I've asked a number of times and nobody really knows. We haven't had a non-zero there since 5.5 was released in 1996.