Versions, updates, open source, and licenses

Your phone probably asks you to update applications so often that you no longer pay much attention to the prompts.

In software engineering, however, versions matter. A modern product may depend on hundreds of packages, tools, and services that continue changing over time.

Knowing which version of each component a product uses helps teams understand how the software should behave, reproduce problems, and make changes safely.

What is a version?

A versionConcept · lights on your mapversionA numbered identifier for a particular release of a piece of software. Naming versions lets a team say “we use 4.2.1” and know exactly which code (and which behavior) they are discussing. identifies a particular release of a piece of software.

For example, a team might say that its application uses version 4.2.1 of a package, and that number helps distinguish the release from earlier and later versions containing different code, features, or fixes.

Versions make conversations more precise.

Instead of saying: “The package is behaving differently on my computer.”

An engineer can ask: “Which version are you using?”

Two machines using different versions of the same dependency may behave differently even when the application’s own code is identical.

Reproducible software environments

Teams often want every developer, testing environment, and production system to use the same dependency versions.

A project may therefore pin a dependency to a particular version, which means specifying exactly which version should be installed rather than automatically accepting any newer release.

Package managers also commonly create a lockfile. A lockfile records the exact versions of the packages and indirect dependencies installed for a project, which helps the team reproduce the same software environment across different machines. Same versions everywhere.

Versions identify the releases. Lockfiles help ensure that everyone installs the same combination of releases.

Reading a semantic version number

Many software projects follow a convention called semantic versioningConcept · lights on your mapsemantic versioningThe MAJOR.MINOR.PATCH convention (e.g., 4.2.1). Patch releases carry compatible fixes, minor releases add compatible features, and major releases may contain breaking changes. A convention, not a guarantee; teams still test updates., often shortened to SemVer.

A semantic version commonly contains three numbers: MAJOR.MINOR.PATCH

For example: 4.2.1

The numbers communicate the type of change the release is intended to contain.

Patch version

The final number is the patch version.

A change from 4.2.1 to 4.2.2 generally indicates bug fixes or other small changes that are not intended to break existing uses of the software.

Minor version

The middle number is the minor version.

A change from 4.2.1 to 4.3.0 generally indicates that new functionality was added while existing behavior was intended to remain compatible.

Major version

The first number is the major version.

A change from 4.2.1 to 5.0.0 may contain breaking changes, and code that worked with version 4 may need to be updated before it can work with version 5.

A useful starting point is:

• Patch: fixes
• Minor: compatible new features
• Major: potentially breaking changes

However, semantic versioning is a convention, not a technical guarantee. Package creators may apply it incorrectly, and even a small update can accidentally introduce a bug.

Teams therefore still test updates before releasing them to users.

What is a breaking change?

A breaking change changes software in a way that may cause existing code relying on the previous behavior to stop working correctly.

Imagine that a library previously offered this function: send_email(address, message)

A later version changes it to require an additional value: send_email(address, subject, message)

Existing code that provides only two arguments may no longer work. The team using the library must update its own code to match the new expectation.

This is why engineers often approach major-version upgrades cautiously. The upgrade may be valuable, but it can require investigation, code changes, and testing.

Updates and patches

An updateConcept · lights on your mapupdateMoving software from an older version to a newer one. The broad word; a patch is the narrower kind, aimed at one specific problem. is a broad term for moving from an older version of software to a newer one.

An update might contain:

• New features
• Bug fixes
• Performance improvements
• Security fixes
• Design changes
• Breaking changes

A patchConcept · lights on your mappatchA smaller update aimed at one specific problem, often a bug or a security hole. “Patch it” means apply the fix quickly. The word covers both the fix and the release carrying it. usually refers to a smaller update intended to fix a specific problem, and security teams may ask engineers to apply one quickly when a vulnerability is discovered.

The word patch can describe both the fix itself and the release containing the fix.

What is deprecation?

A feature is deprecatedConcept · lights on your mapdeprecationOfficially discouraged by its creators and possibly scheduled for removal in a future version. Deprecated code often still works; the warning gives teams time to migrate to the replacement before a breaking change occurs. when its creators officially discourage further use of it and may remove it in a future version.

Deprecated software often continues to work for the moment, but developers are being warned that they should move to a replacement.

For example, documentation might say: “This function is deprecated. Use send_message() instead.”

Existing code may still run today, but the deprecated function could disappear in a later release, which is why deprecation gives teams time to migrate before a breaking change occurs.

When engineers say that an API, function, or package is deprecated, the important questions are:

• What should replace it?
• When will the old version stop working?
• How much code depends on it?
• When should the migration happen?

What is open-source software?

Open-source softwareConcept · lights on your mapopen-source softwareSoftware whose source code is made available under a license granting rights to inspect, use, modify, or distribute it. Linux, Python, React, and most public packages are open source, maintained by volunteers, sponsored maintainers, and companies. is software whose source code is made available under a license that allows people to inspect it and grants certain rights to use, modify, or distribute it.

Examples include Linux, Python, React, and many packages available through public package registries.

Open-source software is a major foundation of modern technology. Companies can build on tools created by individuals, communities, universities, and other companies instead of starting from nothing.

People maintain open-source projects for many reasons. Some are volunteers. Some are paid by companies that depend on the software. Others build businesses around hosting, support, consulting, or additional commercial features.

Open source does not necessarily mean that everything connected to the software is free of charge. A company may offer open-source code while charging for hosted services, support, or enterprise capabilities.

What is a software license?

Making source code visible does not mean that anyone can use it in any way they choose.

A software licenseConcept · lights on your mapsoftware licenseThe legal terms under which software may be used, modified, and distributed. Permissive licenses (MIT, Apache 2.0) allow broad use; copyleft licenses (GPL) can require shared modifications to carry the same license. Legal teams review dependency licenses for exactly this reason. establishes the legal terms under which software may be used, modified, and distributed.

Different licenses grant different rights and impose different obligations.

Permissive licenses

Licenses such as the MIT License and Apache License 2.0 are generally described as permissive.

They allow broad use, including in commercial products, while requiring users to follow conditions such as preserving copyright and license notices.

Apache 2.0 also includes provisions involving patents.

Copyleft licenses

Licenses such as the GNU General Public License, or GPL, use an approach commonly called copyleft, and they may require certain modified or combined software to be distributed under the same license when it is shared with others.

The exact obligations depend on the license, how the software is used, how it is combined with other code, and whether the resulting software is distributed.

Using a GPL-licensed tool does not automatically mean that a company must publish its entire private codebase. However, incorporating or distributing GPL-covered code in particular ways can create obligations that companies need to evaluate carefully.

This is why legal and security teams may review the licenses of packages before approving their use.

Why licenses matter to engineering teams

A package may be technically useful but legally unsuitable for a particular product.

Before adopting it, a company may ask:

• Does the license allow commercial use?
• Must modifications be published?
• Must license notices be included?
• Does the license contain patent conditions?
• Can the software be redistributed?
• Is the license compatible with the company’s other code?

This does not mean every engineer must become a lawyer. It means software dependencies carry legal conditions as well as technical ones.

Managing software over time

Installing a dependency is not a one-time decision.

Teams must continue monitoring it for:

• New versions
• Security vulnerabilities
• Deprecations
• Breaking changes
• License changes
• Compatibility problems
• Whether the project is still maintained

This is part of the ongoing cost of relying on outside software.

A dependency may save months of initial work, but the team still assumes responsibility for managing how that dependency affects its product.

The mental model to remember

A version identifies a particular release of software.

Semantic versioning commonly uses the pattern MAJOR.MINOR.PATCH:

• Patch releases are intended to contain compatible fixes.
• Minor releases are intended to add compatible features.
• Major releases may contain breaking changes.

An update moves software to a newer version, while a patch commonly refers to a smaller fix.

A deprecated feature still works for now but is no longer recommended and may be removed later.

Open-source software makes source code available under a license that grants particular rights.

A software license defines the legal rules for using, changing, and distributing that code.

You should now understand why engineers care about exact versions, why upgrades require testing, and why adopting free or open-source code still creates technical and legal responsibilities.