Related
I'm working on a lot of small utility scripts for users in my office, and I want to develop a release cycle/version number system to use when testing and distributing these tools to users. I'm not sure what the relationship should be between release cycles stages (alpha, beta, release candidate) and version numbers (1.0.1, 1.1.0, 1.2.1 etc).
Say I release version 0.1.0 of a tool. I call it 0.1.0-beta and give it to some users to test. They don't find any problems, so I don't need to make any changes to the code. Do I then just say that 0.1.0 is no longer a beta release, or do I make a new version number?
According to Semantic Versioning 2.0.0-rc.1 (see that version number there) the short answer is you would simply name the released version 0.1.0 which would be considered greater than 0.1.0-beta.
The full nitty gritty is here: http://semver.org
I cannot comment on personal experience with using this approach but it seems reasonably thought through, and there's a discussion relating to it over on its github issues page: https://github.com/mojombo/semver/issues
Note: I'm new to version numbering. Please excuse my ignorance.
I have a project where an attempted major release (Version B) was abandoned then later re-attempted and release (Version C). Each version has major changes from the previous version that I wouldn't consider an minor update. Little to nothing of Version B made it into Version C.
Version A (1.0)
Developed, released, updated, etc.
Version B (???)
Developed, suspended, abandoned.
Version C (2.0)
Developed, released, updated, etc.
I feel like I should have version them like so, but worried about confusion of the missing version:
Version A (1.0)
Version B (2.0)
Version C (3.0)
You should have two versioning schemes. An internal one, that follows the typical form:
major.minor.build.revision
And then a public facing one. With the public facing one, you can map your internal versions to "customer friendly" named versions. Like the hilarity around Java's naming strategies.
I wouldn't mind a missing version number unless it is a marketing nightmare. From a development view point it's simply a pointer and once you make it past a certain point the previous versions only served as lessons to build future versions. Like you said - little of Version B made it into Version C so internally what's the point of acknowledging the existence of Version B?
Marketing - there are plenty of companies that will skip a version number. If customer gets confused just tell them you made such great strides in bettering your product you skipped a whole version. The other side is sometimes customers get this feeling that if they receive a version 2.9 of a software package they are entitled to a free copy of version 3.0. After all - it was on the heels of 2.9. Stop them in their tracks and take some more money for your hard work by a naming convention of 4.0.
That also will help with announcing your EOL by allowing you to EOL the non-existent version and previous making it sound like you're a prince since you main people out there with your newly EOL version of software look like they're already one version off.
It's a mind game - you just have to take control of Russia and China before your opponent does. That's why they call it Risk.
Multi-dot version numbering is a waste of time. KISS. Start with version 1, increment by 1, and just stick to whole numbers. If you're using a system forcing extra periods and digits, ignore them. Keep a good log of what's specific to each version, when it was released, to whom it was released, etc. Anyone deciding only by version number and not the "what's new" documentation on whether or not to upgrade is not anyone to be concerned about.
If Version B was never released, then your Version C can be released with a public release number of 2.0. You don't have to admit to having internal releases that didn't make it. Your internal version number does not have to match your public release numbers, as long as you keep track of the mappings.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Is there any guideline or standard best practice how to version a software you develop in your spare time for fun, but nevertheless will be used by some people? I think it's necessary to version such software so that you know about with version one is talking about (e.g. for bug fixing, support, and so on).
But where do I start the versioning? 0.0.0? or 0.0? And then how to I increment the numbers? major release.minor change? and shouldn't any commit to a version control system be another version? or is this only for versions which are used in a productive manner?
You should start with version 1, unless you know that the first version you "release" is incomplete in some way.
As to how you increment the versions, that's up to you, but use the major, minor, build numbering as a guide.
It's not necessary to have every version you commit to source control as another version - you'll soon have a very large version number indeed. You only need to increment the version number (in some way) when you release a new version to the outside world.
So If you make a major change move from version 1.0.0.0 to version 2.0.0.0 (you changed from WinForms to WPF for example). If you make a smaller change move from 1.0.0.0 to 1.1.0.0 (you added support for png files). If you make a minor change then go from 1.0.0.0 to 1.0.1.0 (you fixed some bugs).
If you really want to get detailed use the final number as the build number which would increment for every checkin/commit (but I think that's going too far).
I would use x.y.z kind of versioning
x - major release
y - minor release
z - build number
I basically follow this pattern:
start from 0.1.0
when it's ready I branch the code in the source repo, tag 0.1.0 and create the 0.1.0 branch, the head/trunk becomes 0.2.0-snapshot or something similar
I add new features only to the trunk, but backport fixes to the branch and in time I release from it 0.1.1, 0.1.2, ...
I declare version 1.0.0 when the product is considered feature complete and doesn't have major shortcomings
from then on - everyone can decide when to increment the major version...
I use this rule for my applications:
x.y.z
Where:
x = main version number, 1-~.
y = feature number, 0-9. Increase this number if the change contains new features with or without bug fixes.
z = hotfix number, 0-~. Increase this number if the change only contains bug fixes.
Example:
For new application, the version number starts with 1.0.0.
If the new version contains only bug fixes, increase the hotfix number so the version number will be 1.0.1.
If the new version contains new features with or without bug fixes, increase the feature number and reset the hotfix number to zero so the version number will be 1.1.0. If the feature number reaches 9, increase the main version number and reset the feature and hotfix number to zero (2.0.0 etc)
We use a.b.c.d where
a - major (incremented on delivery to client)
b - minor (incremented on delivery to client)
c - revision (incremented on internal releases)
d - build (incremented by cruise control)
Yet another example for the A.B.C approach is the Eclipse Bundle Versioning. Eclipse bundles rather have a fourth segment:
In Eclipse, version numbers are composed of four (4) segments: 3 integers and a string respectively named major.minor.service.qualifier. Each segment captures a different intent:
the major segment indicates breakage in the API
the minor segment indicates "externally visible" changes
the service segment indicates bug fixes and the change of development stream
the qualifier segment indicates a particular build
There is also the date versioning scheme, eg: YYYY.MM , YY.MM , YYYYMMDD
It is quite informative because a first look gives an impression about the release date. But i prefer the x.y.z scheme, because i always want to know a product's exact point in its life cycle (Major.minor.release)
The basic answer is "It depends".
What is your objective in versioning? Many people use version.revision.build and only advertise version.revision to the world as that's a release version rather than a dev version. If you use the check-in 'version' then you'll quickly find that your version numbers become large.
If you are planning your project then I'd increment revision for releases with minor changes and increment version for releases with major changes, bug fixes or functionality/features. If you are offering beta or nightly build type releases then extend the versioning to include the build and increment that with every release.
Still, at the end of the day, it's up to you and it has to make sense to you.
As Mahesh says:
I would use x.y.z kind of versioning
x - major release
y - minor release
z - build number
you may want to add a datetime, maybe instead of z.
You increment the minor release when you have another release.
The major release will probably stay 0 or 1, you change that when you really make major changes (often when your software is at a point where its not backwards compatible with previous releases, or you changed your entire framework)
You know you can always check to see what others are doing. Open source software tend to allow access to their repositories. For example you could point your SVN browser to http://svn.doctrine-project.org and take a look at the versioning system used by a real project.
Version numbers, tags, it's all there.
We follow a.b.c approach like:
increament 'a' if there is some major changes happened in application. Like we upgrade .NET 1.1 application to .NET 3.5
increament 'b' if there is some minor changes like any new CR or Enhancement is implemented.
increament 'c' if there is some defects fixes in the code.
I start versioning at the lowest (non hotfix) segement. I do not limit this segment to 10. Unless you are tracking builds then you just need to decide when you want to apply an increment. If you have a QA phase then that might be where you apply an increment to the lowest segment and then the next segement up when it passes QA and is released. Leave the topmost segment for Major behavior/UI changes.
If you are like me you will make it a hybrid of the methods so as to match the pace of your software's progression.
I think the most accepted pattern a.b.c. or a.b.c.d especially if you have QA/Compliance in the mix. I have had so much flack around date being a regular part of versions that I gave it up for mainstream.
I do not track builds so I like to use the a.b.c pattern unless a hotfix is involved. When I have to apply a hotfix then I apply parameter d as a date with time. I adopted the time parameter as d because there is always the potential of several in a day when things really blow up in production. I only apply the d segment (YYYYMMDDHHNN) when I'm diverging for a production fix.
I personally wouldn't be opposed to a software scheme of va.b revc where c is YYYYMMDDHHMM or YYYYMMDD.
All that said. If you can just snag a tool to configure and run with it will keep you from the headache having to marshall the opinion facet of versioning and you can just say "use the tool"... because everyone in the development process is typically so compliant.
Here's one I have always wondered about...
Please excuse my naivety, but - How do you decide what version number to name your software?
I assume, when somebody creates a "final" version of an application/program it is version 1.0? - Then, what happens when you update it, how do you decide to call it 1.1 or 1.03 etc etc.
Is this mostly for the developer?
I've recently heard a pithier versioning strategy, that I first encountered at Eric Elliot's Medium account. It's more weighted towards library versioning that customer facing version numbers, but it has the advantage of simplicity. Use a three part version number, where each number means:
breaking.feature.fix
breaking: Something has changed that means code/expectations must change
feature: Something new is added, but old code/expectations will still work fine.
fix: Nothing's new, but a bug has been fixed.
I leave my old answer below, as it's still relevant to customer facing versions.
I tend to weight the significant digits as follows....
w.x.y.z (or w.xyz)
w - Major version, with many new
features. A paid upgrade. The first
public release of software is 1.X
(pre-release versions are 0.X)
x -
Significant release, but without
groundbreaking new features.
y -
Bugfix releases
z - Patchlevel
releases (fixing an emergency bug,
perhaps just for one client).
If you choose to use the w.xyz format, you only get 9 digits before overflow. However, if you're releasing that often, you may have a bigger problem.
Let's illustrate with FooApp, my new product!
0.9 - The first public beta
0.91 - The second public beta
0.911 - The emergency beta release to fix a crash on the Motorola 68010
1.0 - The first public release
1.1 - Added new BlahBaz feature
1.11 - Bugfixes
2.0 - Totally redeveloped interface.
Jeff Atwood has a blog post about this, where he advocates just using dates, and not to confuse the user with version numbers. However, he does discuss the approach Microsoft has taken: Using dates to determine version numbers. He goes into quite a bit of depth in his post, so I won't duplicate his work here. As for Versioning:
Versions (at least in .NET, go something like this):
1.2.3.4 where:
1 is the major release
2 is the minor release
3 is the build number
4 is the revision number
Major Release - Signifies a 'complete' system with whatever features that version was meant to have. Normally any subsequent 'major' versions are rewrites, or architecture changes, or (excuse the redundancy) major changes to the software.
Minor Release - Signifies a less significant release, with perhaps bug fixes, small features added, or any number of other 'minor' events. This could include interface changes and additions. Normally applications should be somewhat compatible in their 'major release' tree, so minor versions of the same major release should be architecturally the same.
Build Number - Generally signifies just bug fixes, small fixes, and are somewhat insignificant in their scope. It could be something as simple as changing the contrast between the foreground and background of the app. Generally, Builds are internal designations such as nightly builds, so you always have a place to revert back to that is stable.
Revision Number - signifies when bug fixes are released or VERY minor enhancements are made. These are generally reserved for just bug fixes -- don't include major feature enhancements as revisions.
We assign each build of any application unique four part version number defined as Major.Minor.Maintenance.Build.
Major -
The Major number is associated with significant changes to the application. This number also determines compatibility with other applications in the same "suite". This number is incremented when new releases are made. This usually means major architectural changes have taken place.
Minor - The Minor number is associated with new functionality and breaking bug fixes. Any time new functionality is introduced or when a breaking bug fix is applied, this number will be advanced and the Maintenance number will be set to zero.
Maintenance - The Maintenance number is associated with non-breaking bug fixes. This number will be advanced whenever a release is made that contains only non-break bug fixes.
Build - The Build number is associated with the subversion changeset (revision number) from which the application was compiled. This will provide an easy way of matching the version number to a precise set of code in subversion.
The only number the developers are really interested in this scheme is the Build. number. By tying the Build number to the subversion revision number we can guarantee what code was used to create the released application.
I think that the Linux kernel is a good reference for this:
The version number of the Linux kernel
currently consists of four numbers,
following a recent change in the
long-standing policy of a three-number
versioning scheme. For illustration,
let it be assumed that the version
number is composed thus: A.B.C[.D]
(e.g. 2.2.1, 2.4.13 or 2.6.12.3).
* The A number denotes the kernel version. It is rarely changed, and
only when major changes in the code
and the concept of the kernel occur.
It has been changed twice in the
history of the kernel: In 1994
(version 1.0) and in 1996 (version
2.0).
* The B number denotes the major revision of the kernel.
o Prior to the Linux 2.6.x series, even numbers indicate a stable
release, i.e. one that is deemed fit
for production use, such as 1.2, 2.4
or 2.6. Odd numbers have historically
been development releases, such as 1.1
or 2.5. They were for testing new
features and drivers until they became
sufficiently stable to be included in
a stable release. It was an even/odd
version number scheme.
o Starting with the Linux 2.6.x series, there is no significance to even or odd numbers, with new
feature development going on in the
same kernel series. Linus Torvalds has
stated that this will be the model for
the foreseeable future.
* The C number indicates the minor revision of the kernel. In the old
three-number versioning scheme, this
was changed when security patches, bug
fixes, new features or drivers were
implemented in the kernel. With the
new policy, however, it is only
changed when new drivers or features
are introduced; minor fixes are
handled by the D number.
* A D number first occurred when a grave error, which required immediate
fixing, was encountered in 2.6.8's NFS
code. However, there were not enough
other changes to legitimize the
release of a new minor revision (which
would have been 2.6.9). So, 2.6.8.1
was released, with the only change
being the fix of that error. With
2.6.11, this was adopted as the new official versioning policy. Bug-fixes
and security patches are now managed
by the fourth number, whereas bigger
changes are only implemented in minor
revision changes (the C number). The D
number is also associated with the
number of times that the compiler has
built the kernel, and thus is called
the "build number."
Also, sometimes after the version
there will be some more letters such
as 'rc1' or 'mm2'. The 'rc' refers to
release candidate and indicates a
non-official release. Other letters
are usually (but not always) the
initials of a person. This indicates a
development branch of the kernel by
that person. e.g. ck stands for Con
Kolivas, ac stands for Alan Cox,
whereas mm stood for Andrew Morton.
Sometimes, the letters are related to
the primary development area of the
branch the kernel is built from, for
example, wl indicates a wireless
networking test build.
From http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
Whatever numbering scheme you pick, it is critical to make clear to your users when a new version is compatible with old client code versus when a new version requires changes to existing clients. Most projects I know bump the very first number when client code has to change.
Beyond compatibility, I too think there's a lot to be said for using dates. Although it gets embarrassing if, like me, your release schedule is once every two years (but that's for a tool first released in 1989).
More than likely some one in sales or marketing will decide that they need some buzz. This will determine if the next release is 1.01 or 1.1 or 2.0. Kind of works the same in open source but it tends to tied to a fancy new feature that the team is proud of.
A.B.C.D
A: 0 when beta, 1 when first release, larger then 1 on almost entire rewrite.
B: New features added
C: Bug fixes done
The revision number of the version control repository
This is what I use for modules in embedded C projects:
1.00 - Initial release
1.01 - Minor revision
No interface changes to the module (i.e. header file didnt change).
Anybody using my module can upgrade without having to be afraid of breaking code.
I might have done some refactoring or code cleanup.
2.00 - Major revision
Module interface changed (i.e. functions added, removed or functionality of certain functions changed). An upgrade to this revision will most likely break existing code and will require refactoring of code using this module.
I should add that this refers to development stage, i.e. internal releases of modules into the project.
To add to all the explanation above, I will suggest use a versioning scheme which, will be easy for your customers to remember and easy for you to baseline and manage your software versions. Also, if you are supporting different framework such as .Net 1.0, .Net1.1 etc, then make sure your versioning scheme takes care of that also.
some good info here as well..
When to Change File/Assembly Versions
When to Change File/Assembly Versions
First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.
Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.
But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.
Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.
When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.
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.
It depends on the project. below is haskell's package versioning policy.
-- The package version. See the Haskell package versioning policy (PVP)
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary: +-+------- breaking API changes
-- | | +----- non-breaking API additions
-- | | | +--- code changes with no API change
version: 0.1.0.0
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 2 years ago.
Improve this question
My company is building a product. It's going to be versioned by SVN. It's a webapp so basically there will never be a version out which doesn't have some features in them and thus could always be labeled as beta. But since it's going to be a corporate product I really don't want the "unstable watchout" on there. So how would you go about versioning? Is 1.0 stable? Should the build date be in the version number? Tell me what you guys think!
[major].[minor].[release].[build]
major: Really a marketing decision. Are you ready to call the version 1.0? Does the company consider this a major version for which customers might have to pay more, or is it an update of the current major version which may be free? Less of an R&D decision and more a product decision.
minor: Starts from 0 whenever major is incremented. +1 for every version that goes public.
release: Every time you hit a development milestone and release the product, even internally (e.g. to QA), increment this. This is especially important for communication between teams in the organization. Needless to say, never release the same 'release' twice (even internally). Reset to 0 upon minor++ or major++.
build: Can be a SVN revision, I find that works best.
Examples
My current chrome: 83.0.4103.61
x.y.z.g
increments in g are unstable. (or RCs)
increments in z are stable and mean bug fixes.
increments in y are stable and mean new features.
increments in x are stable, major release without 100% backward compatibility.
I once wrote an elaborate "versioning style guide" for a large project of mine. The project failed to materialize, but the style guide is still available online. It's my personal opinion, perhaps it is helpful (or inspirational) to you.
Beware, it's a long text, and goes into component versioning vs. product versioning and stuff like that. It also expresses strong opinions on some versioning schemes popular in the OSS community, but I have them, so I express them. ;-)
I disagree with using the Subversion revision number, for example. You might want to maintain a released version while continuing development in TRUNK, so you'll set up a maintenance branch - and your revision number versioning goes down the drain.
Edit: As a summary, it distinguishes between versioning source files, components, and the overall product. It uses a system of seperate x.y versoning for components and the product, with a nice interdependency between the two that makes tracing which component version belongs to which product version trivial. It also talks about how to handle alpha / beta / release / patch cycles without breaking the system. Actually, it's a modus operandi for the whole development cycle, so you might want to cherry-pick. ;-)
Edit 2: As enough people found my article useful to make this a "Nice Answer", I started working on the article again. PDF and LaTeX versions are now available, a complete rewrite including better language and explanatory graphics will follow as soon as I can find the time. Thank you for your votes!
Get yourself some inspiration from Wikipedia: "Software versioning"
Another "new" and "relatively popular" option is Semantic Versioning
Summary:
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.
a.b.c.d
Increments : when
- d: bug fixes
- c: maintenance, e.g. performance improvement
- b: new features
- a: architecture change
The mandatory is the most left one e.g. if there are for example a new feature and a bug fixed then you only have to increment b.
Based on my experience with complex enterprise platform level dependency management and release versioning I've come to recommend an approach I like to call Semi-Semantic Versioning.
Basically it builds off of Semantic Versioning 2.0 but is not quite as strict.
Semi-Semantic Version Segments:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Primary Release Segment Format:
MARKETTING.MAJOR.MINOR.PATCH
Each segment should allow alphanumerics, but pure numerics are recommended for logical incremental changes.
Like SemVer, I recommend Major, Minor, and Patch components to represent reverse compatibility tiers, but I also recommend prepending a Marketing component. This allows product owners, feature epics/groups, and business concerns to bump the primary component independent of technical compatibility concerns.
Unlike other answers, I don't recommended appending a Build number to the primary segment. Instead, add a Post-Release Segment following a '+' (ex: 1.1.0.0+build.42). SemVer calls this build metadata, but I think Post-Release Segment is clearer. This segment is great for declaring the suffix data as not related to the compatibility info in the primary Release Segment. Your continuous integration builds can then be given the previous release number appended with an incremental build number that resets after each primary release (ex: 1.1.0.0 -> 1.1.0.0+build.1 -> 1.1.0.0+build.2 -> 1.1.0.1 ). Some people alternately like to put the svn revision number here or the git commit sha to make it easy to tie to the code repository. Another option is to use the post-release segment for hotfixes and patches, tho it might be worth considering adding a new primary release component for that. It can always get dropped when the patch component is incremented, since the versions are effectively left-aligned and sorted.
In addition to the release and post-release segments, people often want to use a Pre-Release Segment to indicate almost-stable pre-releases like alphas, betas and release candidates. The SemVer approach to this works well, but I recommend separating numerical components from alpha-numeric classifiers (ex: 1.2.0.0+alpha.2 or 1.2.0.0+RC.2). Normally you would bump the release segment at the same time as adding the post-release segment and then drop the pre-release segment when you next bump them primary release segment (ex: 1.0.1.2 -> 1.2.0.0-RC.1 -> 1.2.0.0). Pre-release segments get added to indicate that the release version is coming up, usually just a fixed set of features for more in-depth testing and sharing that doesn't change minute to minute based on more commits.
The beauty of having all of this semantically defined in a way that covers almost all use-cases is that you can parse, sort, compare and increment them in a standard way. This is especially important when using CI systems for complex applications with lots of small independently versioned components (like micro-services) each with their own managed dependencies.
If you're interested, I wrote a semi-semantic parser in ruby. I needed to not just use this pattern but be able to manage other apps that used it.
"Version numbers" are a matter for your internal version control system. Release numbers are a different matter (and should be KEPT different).
Stick to a simple MAJOR.MINOR release system (like v1.27), where MAJOR is the compatibility level (version 2.x is incompatible with or at least majorly different from version 1.x) and MINOR is your bugfix releases or minor enhancements. As long as you follow the X.Y format, you can also use other systems like YEAR.MONTH (2009.12) or YEAR.RELEASE (2009.3). But really you're probably best sticking to MAJOR.MINOR unless you have a good reason not to.
Definitely don't use anything that doesn't fit the X.Y format, as it'll make it tough for distros, announcement websites, etc. to work with you, and that alone could seriously affect your project's popularity.
Use branches and tags in your (preferably distributed) version control system to mark specific internal version numbers as relating to MAJORS and MINORS respectively.
And yes, 1.0 should be stable. All releases should be stable, unless they're marked alpha, beta, or RC. Use Alphas for known-broken-and-incomplete. Betas for known-broken. RCs for "try it; you'll probably spot things we missed". Anything without one of these should (ideally, of course) be tested, known good, have an up to date manual, etc.
Version scheme: [major].[minor].[devrel][mark]
[major]: increment if you have a drastic change in development.
[minor]: increment if you have a minor change in development.
[devrel]: increment if you have a bug fix. Reset to zero if major++ or minor++.
[mark]: a, b or rc: a is an alpha release, b is beta release, and rc is a release candidate. Note that versions like 1.3.57a or 1.3.57b or 1.3.57rc is before the version 1.3.57. Start at 0.0.0.
It's pretty popular these days to just use the Subversion revision number.
If it's in SVN then why not use the SVN revision number?
If you look at the bottom right of this web page you'll see the Stack Overflow version number which is the SVN revision number.
Versioning is up to you; I'd put 1.0 on the first version I was confident in. You may want to follow it up quickly with other versions, since some software vendors have given 1.0 a bad reputation.
You do want some way of tying the version number to the exact build used, but you probably want it to be nice and simple for your end users. Consider using standard version numbers, and tagging the SVN repository with the version number included.
While just going with the Subversion revision number is nice and simple, it does remove information from the version number. Users might consider this a bad thing.
I assume that your webapp will have some kind of deployment procedure, so that not each revision in Subversion is actually published. Since it is impossible from the "outside" (from the user's perspective) to determine when releases are being made, and how many revisions the code will undergo between them, it makes the numbers almost random. They will be increasing, and I guess it's possible to surmise some kind of distance from comparing two revisions, but not much.
Classical version numbers tend to "dramatize" releases, so that users can build some kind of expectation. It is easier to think "I have version 1.0, now version 1.1 is out adding this and that, that sounds interesting" than to think "yesterday we ran SO revision 2587, today it's 3233, it must be lots better!".
Of course, this dramatization can be inflated too, with companies picking version numbers that are meant to sound more interesting than is motivated by the actual differences in the product, I guess going with the revision number counters this a bit.
We've spent way too much time deciding when to increment the major version. Some shops would rarely do it so you would have releases like 1.25.3 and others would do it for ever release giving you 15.0
I got fed up with that and convinced everyone the major release number is just the year and the minor is just a sequential release within the year. The users seemed to like it and it's a no-brainer to come-up with the next version number.
Year.Release.build
year = current year
release = sequence # of public releases with
new functionality - reset to 1 every
year
build = incremented for bug
fixes and internal releases
EDIT
** Now this was for an internal app that was continually enhanced **
This would probably not work for commercial apps where it's important to have major releases at different times of the year for marketing and financial purposes.
The reason why this question exists is because we don't have a single agreed upon way to do configuration management.
The way I like to do version number is just increment integer from 1. I don't want a multi part version number that I will have to explain or document. And I don't want to use SVN rev number as that will require some explaining as well.
You would need some release scripts on top of SVN to make this happen
I have very little experience in the area. However, here's what I'd do:
Choose a scheme for numbering revisions and stick to it. Be consistent.
Each version change should represent a significant change. How small a change is significant and the levels of change that are reflected in the version number are up to you.
Of course, you can just use the svn revision number --- like many others have suggested!!!
I hope this helps.
We use a simple major.minor.julian_date syntax.
Where;
major - First release is 1 and then when we introduce major new features or changes so significant they are not backwards compatible increase this number.
minor - The major milestone releases. For each build pushed by production this number increases.
julian_date - The Julian Day the build was pushed to QA.
Example of the first release pushed to QA on 1/15 is -> 1.0.015
Example of the first release pushed to Production on 3/4 is -> 1.1.063
It's not perfect, but handy as we push builds to QA near daily.
Some good info here:
When to Change File/Assembly Versions
First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.
Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.
But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.
Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.
When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.
Or to use your 'thought' version number comma subversion number..
z.B.:
1.0.101 // revision 101, release
or 1.0.101-090303 // with release date, i use this