3

In our environment:

  • Internal releases are those which went through testing process. Builds either pass or fail.
  • External releases are those which are delivered to users.

For external releases, version number is surely given. But is it necessary to assign version number for internal releases ?

  • 4
    What is an "external release"? What is an "internal release"? In what ways are they different, and why do you believe that those differences mean a difference in the versioning strategy? – Jörg W Mittag Mar 31 '18 at 19:40
  • i consider internal releases are those which went through testing process like i am working on builds. builds either pass or fail. And external releases are those which are deliverd to users. – shaoor warraich Mar 31 '18 at 19:46
  • Yes, because you need them for reference of (failed) test. – Timothy Truckle Mar 31 '18 at 20:03
  • 1
    Are alpha and beta releases are only internal releases types? or there any other types exist for internal releases? – shaoor warraich Mar 31 '18 at 20:19
  • 2
    How should we know? We cannot tell you what kinds of internal releases you have! Only you know what kinds of internal releases you have. – Jörg W Mittag Apr 1 '18 at 6:30
3

What we've done at my workplace is stamp each build with the build number. Build numbers start at 1 and are monotonically increasing. So every internal build built by our build system gets a new build number. The version ends up being written as x.y.z (build), where x.y.z is the version that will eventually be released (like 5.2.8, or whatever). This also gets written to the executable so we can tell what version is being run. We keep a copy of every build of our product, even if it doesn't get released to customers, and we have way to associate builds with commit revisions in our source control.

1

Common sense

The purpose of version numbering is to identify different releases, with the aim of finding back the exact code corresponding to any version.

In principle you'd be interested in:

  • versions that could still be in use somewhere (either the software was sent outside the company, or inside the company to another department and hence no longer under the control of the product development team).
  • versions that work well, so that if some changes would really screw the things up, you could still go back to the last reliable version, and ship it if needed.

So if a version passed a successful testing process, you'd be in the second case. Hence a version number would make sense, event if it's an internal release.

More formal approach

If you apply Semantic Versioning, the criteria for versioning is still the release:

  1. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

It's not explicitly said if it's internal or external release, but both should be assumed. Because development versions are in principle not external releases:

  1. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Now the SemVer standard allows some liberty in the numbering scheme for pre-releases:

  1. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

It also allows to keep one version number shared between several different builds:

  1. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

So the question here is not so much what distinguishes an internal from an external release, but what distinguishes a build from a release.

In the end, same conclusion as previously: a version that successfully passed a successful testing process deserves to be well identified. If you don't want to follow build numbers in your source control system, then a proper version number should be used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.