Title says it all. What, if any, Is the difference between a software 'release' and a 'version'?
Do these two definitions overlap? Is it the case that all releases, and release candidates are versions, but not all versions are releases?
Here's a simplistic explanation:
Build − executable or a library created by compiling source code.
Version − a software build. New version is a different build.
Release − (public release) a version intended for use by general population.
Build #465832567 is just the number of times the main developer compiled the program (or library). Sensible developers only release builds with meaningful and tested changes.
Version 2.1.5 means it's the second edition with at least 1 major difference from its 2.0.~ predecessors and 5 minor feature updates or bug fixes.
"Public release" usually means it's a version for normal users who are not involved in testing or development of the software.
Different release types example:
Firefox − browser version for simple users
Aurora − so called "alpha" version, which includes latest additions, some untested
Nightly − "beta" version for developers and enthusiasts who don't fear bugs and crashes
I am not sure if there is a very concrete on these two terms, and the definition seems also differs base on context.
Normally Release is more about the "action" to distribute the software to interested candidates, while "version" is an identifier of certain snapshot of the software (mostly a meaningful snapshot).
Therefore, in most case, as we need to identify certain release of the application, we will have a version assigned. (There are always exceptions anyway...)
Definition of version:
a particular form of something differing in certain respects from an earlier form or other forms of the same type of thing.
Think of it this way.
When you edit the code, depending apon what you consider a change (saving, publishing, or just editing), your code version changes (depending on how large of a difference you consider a version- also note that versioning systems can be whatever you decide). You might have a version of code where there is a bug, then you patch it, and you have another version. What you call your versions can be whatever you want (versioning system).
A release is commonly considered a version that is pretty stable, complete, tested and most likely having few known bugs and then made public, although more technically its ANY version made public. However, when you see the word release I feel it is safe to assume it is the first provided you cant figure it out by context.
This is my second post so I hope it was helpful!
A release describes more the process of publishing a software than a concrete material thing. Whereas a version is a concrete and specific software package. Because you won’t publish all software versions you build, only the software versions that you publish or deliver are called software releases. A build is the process of compiling and packaging of a software. Because you can build one and the same code more than once at different machines and with different compilers in different environments a build is the outcome of compile and packaging code and software parts.
Imagine you plan, design, develop, build and test a software. All this steps bring you towards a software release. Because you don’t exactly know how much fixes and versions your team has to build and your quality assurance rejects you must define an objective for you team and your customers. So a release is an objective your team develops towards.
So let’s say you plan your first release in November. The objective of your team is to create a “Halloween Release”. Towards this “Halloween Release” you think it’s clever to present it to our QA before delivering the first version to key users or customers. So the intermediate objective of your team is to create a QA-Release or Alpha-Release. After the 1001st build you present a first running version for example 1.0-alpha-build-1001 to your QA. But your QA rejects this version and the following version as well. So you further fix, improve and build to get a Beta Release that your QA accepts for presentation to key users. Then some builds after, your QA confirms so you can present 1.0-beta-build-4711 to your key users; your first Beta-Release. After some improvements you publish your “Halloween Release” at November with version 1.0 as final software version to your customers. But unfortunately some customers complain about minor issues and some users do complain about missing features. In consequence you decide to fix the issues on the one hand and to integrate new features on the other hand. So your team has two goals and objectives, first to fix and to work towards a “Bugfix release” and second to work for a “Christmas Release” with the new features.
So you fix and build a “Bugfix release”, maybe resulting in a version 1.1. In parallel your team creates new features, integrates, tests and builds a “Christmas release”, resulting in a version 2.0 you deliver at Christmas to your customers.
So in one sentence: A release is a challenge towards a version, you deliver to a particular addresse:
QA-Releases for your QA to examine your software.
Beta-Releases for your key users to introduce new features.
Customer releases for customers to satisfy customers and make money.
Seasonal releases and other releases for funny as serious objectives as well.
Related
I recently contributed some code to an open source library/tool just before I realized that I'd like to re-write this project myself (different programming language and design choices). However, some aspects of the project are just like I would have done them myself or are simply worth "copying". Even if I tried really hard to forget about the original code -- most class names, constants and other stuff just are naturally named the same. The original project's license is AGPL.
Can I use a different license (e.g. MIT)? Which ones?
Will I have to mention the original project somewhere?
If so, where? And will I ever be allowed to remove the notice (maybe after the two projects have truly diverged after a few years of development)?
I am not a lawyer and this is probably not the correct venue for soliciting legal advice.
However, this is my take, as one FOSS contributor to another.
Generally speaking when you contribute to open source projects, you retain the copyright over the code that you wrote, and you release it under a license that permits everyone to use modify and distribute it.
Thus, you retain the right to relicense code that you so contributed under MIT or another license. That doesn't count as "stealing" the code and erasing the GPL license -- you were the original source and you retain the right to release what was originally yours again under a different license.
In some projects, the leaders may request that people DO transfer copyright, although its pretty rare I think. You should check the licensing statement to be sure. Unless there is something in writing somewhere saying that you explicitly agree to transfer copyright to them, then most likely you retained it.
You do not have the right to relicense other peoples work though. In cases where you modified someone elses code, contributing some changes to their class or something, you probably become joint owners, and at least I would not feel comfortable copying the part that they made and relicensing it without permission.
That's just the text of the code though. If you want to rewrite another program from scratch, using a similar high level plan but different execution, I don't think copyright will encumber you. Intellectual property law can still encumber you if some technique or method in the code is covered by a software patent. But it doesn't sound like that's the case here.
To avoid legal issues, sometimes companies / groups of people will use "clean room design" (https://en.wikipedia.org/wiki/Clean_room_design). But iiuc this is just done as a precaution to unambiguously head off any possible lawsuit -- the law does not require that you use such techniques just because you once looked at GPL code, iiuc.
For an example of this playing out, you can look at the history of the MinGW cross compiler project, and the mingw-w64 spin-off of it, which originally began because a private company wanted a version of mingw which supported 64-bit processors and other things, and so used clean room design to reverse engineer the project. The result of this was eventually made fully open source, but was not accepted back into the original mingw project and so there are now two projects. (Hope that this is a fair and impartial summary of the history.)
https://en.wikipedia.org/wiki/MinGW#History
In application life-cycle management, it's common to have some environments. For example:
DEV -> Staging -> Production
Normally, you would develop in the DEV environment and stage your developments to Staging and Production.
But it's possible to directly modify the PRD environment (to quickly fix a bug, for instance).
How do you call this procedure (the modification of your code in an environment that is not the DEV environment)?
I thought it was called "hotfix" but I see no related search results in Google.
As opposed to your reference entity Environment the entity is, in my opinion, Branch within your SCM.
With this in mind, you are absolutely right: In my experience it was always a Hotfix branch. For planet TFS where I currently reside, this is described in various branching guidelines including this one - which is considered to be among the best (if not THE best).I had similar experiences in a UNIX/ClearCase planet, again with Hotfix branches - they were named as "MaintenanceRelease"-branches. Those contained one or more Hotfixes, occasionally a highly anticipated Feature could be merged into that as well.I wouldn't ever expect to see in any company a "Hotfix"- Environment. 'Hotfixes' address any possible crisis that a customer has experienced and that is per definition pretty vague. So having such an environment, is possibly a Utopia. In one occasion, they had a "BLS" - lab ("Back Level Support") which was used by Support-People to reproduce customer scenarios. Hotfixes provided by Development were deployed in this Lab before release. This is in some extend a "Hotfix" environment - still, beware that this installation costed millions.
Which best practice involved in software configuration management to help in improving project management?
It mitigates a whole bunch of project risks, including:
The risk of making a change which is found to be incorrect: SCM software allows you to see the change and roll back
The risk that you could lose all your source code (much less likely since everyone has a copy on their machine)
The risk that two people could make incompatible changes: good SCM will allow you to merge the two and get the best of both worlds.
Also, these days SCM is so easy and cheap to set up that embarking on a software project without it is madness.
Assuming you're really focused on best practices, I can outline a couple of possibilities.
Using the best (SCM) tools available. While this might depend on your specific goals and constraints, Mercurial and Git are hard to beat (distributed, excellent branch/merge capabilities, multiplatform, FOSS, really fast, flexible workflow etc.).
You can analyse the data in your source repository using a tool like PanBI (disclaimer: I wrote it). A short screencast shows off what you can learn from repository contents analysis. In brief:
general work dynamics on the codebase
breakdown per developer
daily work dynamics
type of changes to the codebase (add/remove/modify), part of the source tree
...and much more.
Connecting an SCM tool with an issue tracker can also add value. Developers place issue ID's in commit messages, e.g. "[#1455]: improved performance a bit" and the issue tracker relates the issue with the changes in the code repository. From a project management perspective, this allows you to loosely track the time spent on individual issues, project phases or complete projects. A simple commit hook refusing commits without an issue number can go a long way in ensuring data consistency. Such "measured" data can be compared to the baseline to understand what's working and what isn't.
Building official releases on a build server from a tagged source version pulled from the repository could also be considered beneficial from a project management perspective because it's a way to control quality. Building software this way detaches the build process from any dependencies or specifics of developer machine environments, provide reproducibility, allows robust automatic/semiautomatic publishing of the build etc., i.e. streamlines and shields parts of the deployment process.
These are just some of the possibilities, it doesn't stop here.
What is the best method to determine the version number I should use for a software or component? Is there a general rule to set version numbers?
I'm pretty sure it is a basic question but I didn't find anything useful after searching a while.
Microsoft have a convention of:
[major].[minor].[revision].[build]
Or follow Jeff's versioning system.
I've been doing this as an interim until I find a better solution. I don't build many large applications, mostly reports and smaller macros, but it's still important for me to keep track of changes and versions.
[Current year].[Current month].[Current day]
FileName 9.7.17.rpt for example.
It works for me and my boss, and it gives a value which you can compare to today's date to see how old the file is. I also keep a changelog.txt file in the same folder as the most current version and it keeps track of all the changes from the previous versions. I also keep track of all versions in a version control page on each projects tab in OneNote.
Thanks for the answer. I'll also throw in how I store the projects for giggles.
Every project gets its own folder. Inside that folder I'll have 4 main items that help me keep track of what's going on in the project.
An old versions folder
A folder for any reference material I might need for the project
The actual project file
And the changelog
That tree will look something like this.
Project X
Old versions
X Report 9.4.12.rpt
X Report 9.5.3.rpt
X Report 9.7.20.rpt
Reference
SQL calls.txt
Client list.txt
Procedures.doc
X Report 9.7.29.rpt
X Report changelog.txt
This way of keeping track of my work really cuts down on the amount of time that I need to spend documenting anything and organizes it in a standard way so if my boss needs to grab something I've worked on, even he knows exactly what everything means and where it is.
For storing multiple projects in my network folder I have these folders.
Inbox
Projects
#Archived Projects
Current Project 1
Current Project 2
Current Project 3
Reference
Inbox is where I toss random things to process later, or a folder where my boss can throw something I'm going to need for a later project. The Projects folder contains all the projects I'm currently working on, and then when I'm done or they no longer become a current priority, they get tossed in #Archived Projects. Reference is a folder for general job reference material, like policies and procedures, phone lists, org charts, fire escape plans. I may never use them, but it's comforting to have a place to put that kind of stuff as opposed to digging through old email.
This is a very common question. Are you sure you searched around? Wikipedia has a good article on software versioning.
Or, you can follow Ubuntu's convention of using year and month.
For example, release on April 2009 would be:
v9.04
Do it like Donald Knuth does with TeX---its version converges to π with each release and will in fact become π when he dies.
Since version 3, TeX has used an
idiosyncratic version numbering
system, where updates have been
indicated by adding an extra digit at
the end of the decimal, so that the
version number asymptotically
approaches π. This is a reflection of
the fact that TeX is now very stable,
and only minor updates are
anticipated. The current version of
TeX is 3.1415926; it was last updated
in March 2008.
from Wikipedia
A common scheme seems to be to use [major].[minor].[revision]. Where the major version number increments on large/major feature changes or rewrites (or stays 0 as long as you didn't reach a stable version, although many open source projects never get past 0 here), minor version number increases on minor changes, such as a collection of bugfixes, an added small feature and the like. revision increments with each build and reflects the smallest granularity of tracking your exact version. Things like small fixes, etc. get rolled into this, usually.
Usually the first number are major changes/major releases, the second number are used when minor features and bug fixes are added, and the third number is used for minor bug fixes and revision numbers.
Ex. 1.0.0
Depends on a lot of things.
If you are doing .Net work, you can have the system keep track of version numbers for your .dlls and .exe files automatically.
We frequently use the subversion revision as part of our version number. We use a system like:
major.minor.svn-version
We increment the major/minor manually based on internal decisions, and have the svn-version propagate to distinguish builds.
The most important thing is that version numbers make sense to your users.
Context: I work at a small software company that has traditionally done research-type work, and does not have much experience in the commercial space. We are now trying to push into the commercial world. Due to our origins in research we are used to a very rapid development cycle and very little structure in terms of maintaining proper versions of projects.
Problem: The lack of structure is now proving to be somewhat of a hindrance, as every developer has a slightly different view of the code base. A problem one developer discovers is not reproducible by another developer, and problems found in one build may disappear in the next (or worse, new problems may appear). This makes for a very frustrating experience for someone who is responsible for integrating all the projects and ensuring quality and performance standards are met - i.e. myself.
Potential solution: Personally I am convinced we need to enforce better structure via fixed version numbers and regular releases. It should be self-evident how proper versioning would help with many of our problems, but of course it is not without problems - developers need to do extra work to perform and test releases, and will no longer be able to use the latest versions of everything.
Question: To come to a point - what sorts of strategies do you recommend for ensuring the process and effort required for releases occurs as smoothly as possible? We are using git for version control, maven for our build system, and we have bug tracking and continuous integration systems running, so I believe the tools are there. I am simply unsure about what a proper release process should look like.
You have the big three in place: version control, one-click build via Maven and your continuous build server, and bug tracking. It sounds like you guys are gravitating towards Agile methodologies, and so you ought to be trying to keep the trunk version of your product in a near deliverable state at all times.
When you decide to make your first release, create a branch off of your trunk version for that release. Decide on a labelling scheme and be sure to label the branch version. For example, your first release could be 1.0.4530, where the 1 means first version, the 0 means it's the first release candidate, and the 4530 is the version control change number. You test this release branch and fix important bugs on it. After a while you issue another release candidate, say 1.1.4807. This process iterates a couple more times (say), your release becomes good enough, and you ship version 1.3.5167.
Meanwhile, your new development occurs only in the trunk version, and from time to time you'll need to merge bug fixes from the 1.x release branch back to the trunk. Later, you'll split off a 2.x branch from the trunk to repeat the process for your second release. You'll generally have several active branches (plus the trunk), with development limited to the trunk and each branch kept pristine and independent from development.
You guys will get the hang of things and your developer coordination problems will become less frequent. But these problems are nearly all going to be limited to the trunk, not the release branches.
A problem one developer discovers is
not reproducible by another developer,
and problems found in one build may
disappear in the next (or worse, new
problems may appear). This makes for a
very frustrating experience for
someone who is responsible for
integrating all the projects and
ensuring quality and performance
standards are met - i.e. myself.
Potential solution: Personally I am
convinced we need to enforce better
structure via fixed version numbers
and regular releases.
I don't think you need to have very frequent releases just to coordinate internally. You can do that through version control. Just have people talk about specific git revisions when reporting issues. Also note that you will have to coordinate any external dependencies/libraries too. Some kind of vendor branches could help with this.
It sound like the developers need to use "test branches" and respect the "stable/production branch" a little bit more.
Sell in the concept of "do your wild west stuff in this branch", and when you are happy with the results then you merge it into this "boring stable production branch"....
(or something like that)
There are books written about the general topic; Amazon search even returns three titles for specialized "version control with git."
I think you will benefit from defining a canonical view of the code base. Call it Test. A problem is a problem if it appears in Test. If a problem does not appear in some developer's view, it is up to that developer to figure out what is the important difference; and likewise for a problem that appears in a developer's view, but not in Test.
One convention is for Test to be re-built from sources on a nightly basis. A more strenuous convention is for Test to be re-built upon every update. If your team is small (five or fewer) and not dispersed over great distances or multiple timezones, a reasonable first approximation is to make Test a git workspace on a server upon which your toolchain has been installed along with some cron jobs so that this workspace is updated and rebuilt every night (usually).