055.2 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
055 Project Management |
Objective: |
055.2 Product Management / Release Management |
Lesson: |
1 of 1 |
Introduction
Most software evolves in many ways over time. In fact, that’s one of the wonderful things about software: It’s easy to change and requires just a network transfer to update everyone who’s using the product. So developers add new features, fix bugs and security flaws, port the software to new hardware, and add interfaces to popular programs and services. As the software changes, new versions or revisions are released.
This lesson covers the logistics for planning and making changes to software, how teams juggle multiple versions, conventions for naming the versions, and other organizational aspects of development that are a subset of the actvities involved in project management. The logistics that apply specifically to the timing, naming, and control of releases is known as release management.
Characteristics of Releases
Releases vary in terms of stability, backward compatibility, and support. We’ll examine each of those concepts in the following sections.
Stable and Unstable Releases
Stability is a key trait users expect from software. The first question many ask, upon hearing of a new release, is “How stable is it?” In other words, will it work reliably, or will it crash, corrupt data, or produce incorrect results?
Stability can be measured on a spectrum, and many people are happy to use software even when there are still some bugs. But development teams tend to keep things simple, and talk in binary fashion about stable and unstable releases.
Stability refers both to the bugginess of the software and its likelihood to change in ways visible to outsiders. Developers might consider a release of a software library unstable because they have changed the functions that programmers call (that is, because programmers might have to rewrite their software for the next release). Or software might be unstable from a user’s point of view because developers have removed a feature.
Is there any reason to release an unstable version? Yes: They are valuable for letting users try out new features early in the project and test for bugs.
Most projects release very early revisions of software for key clients to try out; these are called alpha releases. No one should use these releases for real work — they are only for testing. In fact, testers should run alpha releases on computers that aren’t doing any important work, because bugs in those releases could actually damage data stored on the computer.
When the software is close to being considered stable, the project usually release another test revision called a beta release. These should still not be used for production work, only for testing.
For both alpha and beta releases, the developers have a process for reporting bugs and tracking the progress toward fixing bugs.
Some projects include another stage between the beta and stable releases, when developers have fixed all the bugs they can and think that the product is done. They call the version a release candidate and show it to key customers or stakeholders so that these stakeholders can plan how to use new features.
Finally, some projects put in features that are not quite stable, because important users have requested them. The developers intend for users to try these features and say whether they like them, before developers finalize the interfaces and invest the effort to stabilize the features.
Backward Compatibility
Most projects seek backward compatibility, meaning that they try not to remove features or functions that existed in older versions. Compatibility can exist on several levels. For instance, if the developers maintain backward compatibility for the application programming interface (API), they promise that old source code can continue to work, but it might have to be recompiled. If hardware vendors or operating system developers maintain backward compatibility for the application binary interface (ABI), they promise that in addition, old executable files can run on new versions of the hardware.
We’ll look later at the ways projects handle a lack of backward compatibility, when they decide that the old interface really doesn’t work for the new features or environments they need to support.
Support and End of Life (EOL)
Software would ideally get better and better as developers discover and fix its problems. But over time, features can stop working because of changes in the software’s environment. Also, new bugs are discovered that were hidden before.
New versions often combine security and bug fixes with new features. You might not want the new features (in fact, you might prefer some old feature that the developers removed in order to make way for new ones), but people usually upgrade to the new version to get the security fixes that will protect them against malicious attacks.
Some people actually keep using old versions of software, refusing to upgrade. This is normally because the new version breaks something that was working in their environment. When companies charge money for upgrades, some customers refuse to upgrade because they don’t want to pay the extra money, but paying for upgrades is rare in open source.
Developers accommodate the users of old versions, if possible, by fixing bugs in the old versions without adding the features that break the software. Naturally, the developers can’t do this forever because it drains time and energy from new work. There will come a time when they refuse to fix an old version and tell the users either to upgrade or to make their own fixes.
Fixing bugs and security flaws is called support for the software. This is different from the support offered by helpdesks and other people who guide users in understanding the software. So far as release management goes, a supported release is one where the developers promise to fix bugs, whereas an unsupported release is one where they do not.
Note that the notion of “support” applies mostly to software created by companies or large organizations. Smaller open source projects, depending heavily on volunteers, often promise just to do the best they can to fix bugs and put out new versions. They don’t see a need to fix old versions. Because the code is open source, users who don’t want to upgrade can pay someone to fix an old version.
When support is in place, developers publish a schedule indicating how long they’ll support each version. The date where support ends is called the software’s end of life (EOL). Users can keep the old version up to EOL and expect bugs to be fixed, but after EOL they have to upgrade or take their chances.
Major projects, such as the Debian distribution of GNU/Linux, offer long term support (LTS) versions. That simply means that the developers will keep fixing bugs for a certain number of years. Customers who value stability highly might be afraid to install versions of software that have lots of changes, in case the changes break processes that the customers rely on. Such customers, notably large institutions, like the security of LTS versions.
Software Versioning: Major, Minor, and Patches
We’ve seen that versioning is complicated: Some versions fix bugs, while others add features, and the versions can vary in stability. Developers try to indicate through labels how big a change to the software is in each version. The conventions adopted by nearly all projects for labeling versions are called semantic versioning.
Let’s take the early history of the Linux kernel as an example. Linus Torvalds labeled the first stable release 1.0. As he improved the kernel, he labeled subsequent versions 1.1, 1.2, and so forth. The initial 1 was the major version and the numbers after the period denoted the minor version. You could assume that version 1.2 had more features and offered more than version 1.1 did.
But there were also innumerable small releases, sometimes just to fix a few bugs. To show that the changes had a minor impact on the use of the kernel, Torvalds included a third number called the patch. Thus, 1.0 was upgraded to 1.0.1, then 1.0.2, and so on.
Patch numbers start over at 0 when a new minor version is released, and minor version numbers start at 0 when a new major version is released.
Developers lump together versions using an “x” to indicate that they’re talking about multiple versions, such as 1.x for all versions under major version 1.
But what’s the difference between a change that leads to a new minor version and a change that deserves to trigger a new major version? Usually, years pass before a new major version is released, and it has to reflect a very significant upgrade.
Generally, developers try to keep backward compatibility as versions change. If backward compatibility cannot be preserved, developers should increment the major version.
Sometimes you see a version number less than zero, usually 0.9. The leading zero indicates an early version of the software that is unstable and unready for production use. There is no guarantee of backward compatibility until the developers release versions starting with 1.
Alpha versions are usually indicated by appending “a” or “alpha” after a release number, such as 3.6alpha. Similarly, beta versions append “b” or “beta” after the release number.
The Software Product Lifecycle
Don’t think the life of a developer is easy. Everybody wants something from them. I want this bug in screen layout fixed A.S.A.P., whereas someone else says that the bug in filenaming takes precedent. Users clamor for new features, and when different developers work on different features in parallel, they find that one’s changes may trample those made by another.
Project management, and the subset of these tasks called release management, deal with these issues. Usually, a senior project member takes on responsibility for this management job.
Like people, software versions go through a lifecycle. Each one begins with a discussion of new features and other changes needed, goes through development and test phases, and is rolled out in a planned manner.
Planning and Roadmaps
Developers try to lay out, far in advance, what changes they want to make to a product. In commercial firms, they talk to marketing people, who filter and summarize what their customers tell them. Open source projects depend more on ideas submitted by developers and users, which are captured in a database called an issue tracker. If you need a bug fixed or want a new feature, you fill out an issue. Developers then prioritize the changes and decide who will handle each one.
So how are changes chosen and prioritized? It can be a messy process. But good project managers on open source projects encourage broad input while ensuring that decisions get made. Some projects even hold conferences where participants hash out the priorities.
A published roadmap lays out the resulting plans for enhancements and changes. It may extend many releases and many years into the future. Each step is called a milestone, and might or might not be associated with a target date.
Release Scheduling
There are two basic ways to schedule releases: time-driven and feature-driven. A project can promise a release at regular intervals — every six months, for instance — and include whatever is finished at that point. Alternatively, the project can promise to include certain features in a release, and let the developers take as long as they need to finish those features.
As the time for the release approaches, the release manager determines dates for the alpha, beta, and stable releases. Team members regularly review bug reports and try to plan their work so that they meet these milestones.
In order to finish a release, a project has to stop accepting ideas for new features and focus on making the existing features work right. This moment is called a feature freeze.
Documentation for Product Versions
Roadmaps, as mentioned earlier, explain the features that developers plan to include in each release. The release is accompanied by a list of changes called a changelog. Generally, the changelog lists new features, changes to existing features, features that were removed, features that the developers intend to remove in the future (known as deprecated features), and bug fixes.
Thus, changelogs can get quite long and detailed. Users need to pay special attention to features that were removed or are deprecated, because the users might have to change their programs or way of using the product. Obviously, developers try to remove only those features that nobody needs any more.
Each release should change product documentation to match changes in the product. This task can be time-consuming, and it’s easy for developers to miss a change or lag at producing documentation.
Guided Exercises
-
What distinguishes a stable release from an unstable one?
-
Would you expect a feature change between a release named 2.6.14 and a release named 2.6.15?
-
Would you expect a feature change between a release named 2.6.0beta and a release named 2.6.0?
-
Why would you expect release 1.0 not to be backwardly compatible with release 0.9?
-
If you discover a security flaw in a version after a feature freeze but before its release, can you get the flaw fixed?
Explorational Exercises
-
Suppose you want to keep using a version of open source software after EOL, because it has a feature you need. What can you do to keep it usable?
-
What are some criteria that allow one bug fix or feature request to be chosen over others?
Summary
This lesson described the main characteristics that distinguish releases: stability, backward compatibility, and support. We discussed the meaning of version names and numbers, and key aspects of release management, including documentation.
Answers to Guided Exercises
-
What distinguishes a stable release from an unstable one?
Releases are considered stable in two ways: They work well without crashing or producing incorrect results, and the interface presented to users or programmers is expected to be backward compatible with previous versions.
-
Would you expect a feature change between a release named 2.6.14 and a release named 2.6.15?
No. The third number in semantic versioning indicates a patch, which was made to fix a bug or carry out some other minor task such as reformatting. A feature change should lead to a minor or major release.
-
Would you expect a feature change between a release named 2.6.0beta and a release named 2.6.0?
No. The beta version is a test version that contains all the features to be included in the final release.
-
Why would you expect release 1.0 not to be backwardly compatible with release 0.9?
The number 0.9 explicitly warns potential users that the software is still being designed and could very likely have a different interface when it is stabilized as version 1.0.
-
If you discover a security flaw in a version after a feature freeze but before its release, can you get the flaw fixed?
Most certainly. The period between a feature freeze and the release is meant as a time to discover and fix flaws, including security flaws.
Answers to Explorational Exercises
-
Suppose you want to keep using a version of open source software after EOL, because it has a feature you need. What can you do to keep it usable?
After EOL, the project developers have no commitment to fix bugs, including security flaws. Therefore, you should follow the project’s bug tracker and mailing lists assiduously to find out what bugs turn up. Because the code is available, you can and should fix bugs that are in your version. In theory, you could even incorporate new features into your version. That would effectively make your version a fork of the original.
-
What are some criteria that allow one bug fix or feature request to be chosen over others?
For bug fixes, criteria include severity (which is assigned to the bug after it enters the bug tracker) and the number of users affected by it. For a feature, criteria include the number of users who want the feature, the difficulty of coding it, and its potential impact on other parts of the program.