I recently learned that there are a plethora of WebSocket protocol specifications (a bunch of them named hixie-, another bunch of hybi-, and finally a RFC 6455).
I assumed that hixie- and hybi- were previous drafts, and that the RFC is "the final word" towards all the implementations will eventually converge. However, I was surprised to discover that the RFC is from December 2011, while the latest hybi-* is from February 2012.
Could someone please shed some light? What is the historical development of all those branches and what is the roadmap for the future?
By the way, do those funny names (hixie and hybi) stand for something?
"Hixie" stems from Ian Hickson ian#hixie.ch .. original proposer/author of the WebSocket protocol.
"Hybi" stems from "hy_pertext bi_directional" .. IETF working group "BiDirectional or Server-Initiated HTTP (Active WG)".
The latest and final RFC is RFC6455. Do implement that.
Hixie-75/76 are deprecated, security flawed, outdated versions that were in use for some time.
Hybi-Draft-N .. where N is .., 10, .., 18 mark revisions of the protocol during the development of the final RFC from draft RFCs.
Everything >= Hybi-10 are only small variants of the final RFC6455.
In short: read and implement https://www.rfc-editor.org/rfc/rfc6455 and you will be fine.
Related
We are starting a new project and it won't be done for 2-3 months. Should I build on version 3.0 since beta 3 was just released or continue with 2.5 and convert over when 3.0 stable is finally out?
You will need to define what "safe" means to your standards.
Safe as to security? I'd say pretty much yes. The project has 10 years on its back, potent programmers, several eyes that scrutinize it since early alphas, so I wouldn't expect anything major to slip there because of the beta status.
Safe as to whether it's close enough to be coming out and not become vaporware? That's a definite yes. You can check the daily active development and the number of people that commit to the code and docs to be sure about it. It's no "one man's project" to worry about.
Safe as to "good code investment"? That too is a yes. While there won't be that many plugins or code example for the first months as are now for 2.x, the new ORM is a joy to work on, much faster and cleaner and once finished you'll have a project on recent codebase that won't require major rewrites. Of course until it hits RC there might be small API changes that you will need to follow but nothing as breaking as alphas or anything that will require you to scrap your code and start over. Once on RC (most probably during December) you might as well consider it as stable as a normal release.
Safe as to performance? That is a yes as well. Tests show that it is as fast as 2.x but has so much more to offer. No worries about bringing your server down because of "beta" status. It might get more optimized in the future but if it starts from the same ground as 2.x it means it will only get faster.
The only "no"s are if safe is defined by "stick to old well tried code to minimize every crazy risk" or if you have a project that can rely on code others have written and won't be touched again in the future unless something breaks.
As they have said in their latest tag release notes:
The CakePHP core team is excited to announce the release of CakePHP 3.0.0-beta3. While we had originally planned on only doing 2 beta releases, we're not entirely satisfied with the current ORM validation workflow, and want to do some additional work there. The new plan is to have at least two RC releases after beta3. The RC releases will be API frozen and no new features or breaking changes will be added.
As the period between their last pre-releases was about a month (except the last one with 50 days):
beta3: Nov 17,
beta2: Sep 28,
beta1: Aug 23,
alpha2: Jul 28,
alpha1: Jun 26,
You can do it at your own risk!
Furthermore, I prefer to wait for a few releases after their stable release and fixing newly mentioned issues by people intending to use their code for production.
The internal application which my team works on is currently on a version 10.y.z.build_number.
During a discussion if the next release is significant enough for 10.y+1.z.build_number or it should be 10.y.z+1.build_number I suggested that we could keep it simple and align the version numbers with the calendar.
For example the next release would be 13.8.1.build_number which stands for the 1st release for August 2013. The September one would be 13.9.1.build_number.
The idea has been discarded for now.
For a paid application I can imagine that having the 1st number is useful to easily distinguish between releases with free upgrades and major releases which require paid update. x+1.y.z would be paid and x.y+1.z would be free.
After a quick search I found Jeff Attwood's What's In a Version Number, Anyway?.
However for an unpaid internal application I cannot think of weak points for the calendar-aligned version numbers and the beauty of simplicity speaks to me. As one of the comments on Jeff Atwood's post says: Microsoft Office 2003 is a far more meaningful name than Microsoft Office 11.
The question:
Is my vision clouded by enthusiasm and are there known issues for calendar-aligned version numbers?
For an internal application, the information that the version needs to convey is the revision or commit of the sources from which said app is built.
Since you have access to the VCS managing that app sources, the version can help bug reporting like: "found in revision xxx".
That is far more valuable that a date-based tag, which can be subject to interpretation in order to find the exact version of the sources exhibiting a bug that need to be reporting.
You can combine that with any version policy you want, with tags: git, for instance, can generate a unique version number based on SHA1 + a tag. See:
"Deriving application build version from git describe - how to get a relatively straightforward string?"
"Simulating a global revision number with git"
But the idea remains: date is a metadata managed by a VCS or a build scheduler like Jenkins/Hudson/TeamCity... It doesn't have to be in the public version number of the app.
What need to be in that version number is an info allowing to get the exact sources from which that app was built.
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.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Suppose I have a web application with some basic functions. I want to market it. So I would like to assign a version number - something like 0.0.1. What I want to know is are there any constraints that should apply to that numbering system?
Hope you understood my question, thanks in advance.
Most places use something like this:
Major Release.Minor Release.Hot Fix.Build
Your version numbers would look like 1.5.0.15, etc.
A lot of free software uses a three point system: X.Y.Z where
X is for compatibility breaking releases.
Y is for other releases, with even numbers being stable and odd numbers being unstable.
Z is for fixes.
This way version 0.28.1 is a stable release with one fix and 2.9.0 is an alpha release with zero fixes.
Some people also have fun developing their own schemes. E.g. Tex which by each release approxed Pi, with version numbers: 3, 3.1, 3.14, etc.
It does not really matter, as long as you can use the version number to identify your versions (i. e. either add your source control system's internal revision number into the version number) or use it for tagging your releases.
When you do so, you might want to use that number as your third (or fourth) component. It looks confusing if some product jumps from version 1.12345 to 2.12346, but jumping from 1.4.12345 to 2.0.12345 is more common.
About which number to start, I just want to quote Eric S. Raymond:
In the closed-source world, Version
1.0 means "Don't touch this if you're prudent."; in the open-source world
it reads something more like "The
developers are willing to bet their
reputations on this."
You can use whatever numbers you want in your versioning - who's going to constrain you?
If you want your first version to be 0.0.0.0.0.0.0.1, that's fine, albeit a little silly. If you want your first version to be 106.3, you can do that too, but that's a little more ridiculous.
Check out the Wikipedia article on Software Versioning for some tried-and-true ideas of realistic version numbering schemes.
I've always used (rewrite).(feature added).(bug fix).
But set your own rules and make them public so your users understand them.
Take a look here. python setuptools has a very interesting and clear specification for version numbering. I'm sure you can obtain some very insightful hints from it.
To the best of my knowledge, there is as yet no government agency dictating how you number versions. But don't worry, I'm sure it will come soon enough.
Ditto on those suggesting major-dot-minor-revision. My general approach is: Major changes get a new major version. Like, if we've added important new features. Small changes, like added some little convenience features or one new report, get a minor revision. Hot bug fix changes get a revision.
I would definately avoid calling your first published version "0.l" for simple marketing reasons: Numbers less than 1.0 sound like a preliminary version or a beta version. I've known people to call their first version 2.3 or some such just to make it sound like it's been around a little while to inspire more confidence, though that strikes me as a little dishonest.
how about the software which is not distributed to public like a webmail source code? do you think that the build or bug fix number is still important in this case?
10.50.1600.1
major.minor.build.revision
MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.
MINOR changes is backward compatible. Mark introduction of new features.
REV for security/bug fixes. Backward and forward compatible.
eg. In SQL server 2008 RTM version number is 10.00.1600.22 and In SQL server 2012 version is 11.00.2100.60
First field is changed due to change in project name i.e. 10 and 11
In SQL server 2008 R2 RTM version number is 10.50.1600.1 and In SQL server 2008 version is 11.00.1600.22
Second field is changed due to introduction of new features.
Third field indicate build(developed)
Forth field indicates revision i.e. hotfixes applied...
You might want to start by taking a look at the Software versioning article on wikipedia, which gives some informations about the possibilities you have ;-)
It might give you some ideas of what you could do in your specific case...
I've used
Major.Minor.Release.Build
1.02.4.15
and also
Year.Month.Date
2009.12.10
but anything that allows you to individually track releases would work. As long as you're consistent.
We use major.minor.revision.build where revision is the SVN revision and build is the build number which is based on the current date (in YYDDD format where YY is the year and DDD the day number, so 18001 would be Jan 1st 2018.)
Having the SVN revision is incredibly useful and has saved us on more than one occasion.
Version numbers are not a concrete specification in software development.
In other words, one team may use 1.0.0.0, others may use 1.0.0 and so on. It matters not.
Just choose something that works for you.
Typically major.minor.revision is the most simple and straight forward method to use. Visual Studio for example can assign version numbers automatically for you, as can other tools. So all you are required to update is the major/minor values. The build/revision numbers are updated automatically.
I seem to remember that in the old days (I am talking Commodore here) we used a syntax like
release.version.revision
which could be appended with either fix and/or build, where fix would usually be a letter stuck directly to the revision. So a full number would read something like:
2.1.44a.786
But like most have already said, it doesn't really matter, there is no true standard for this. Just use whatever is most convenient for you.
After reading a lot of articles/QAs/FAQs/books I become to think
that [MAJOR].[MINOR].[REV] is most useful versioning schema to
describe compatibility between project version (versioning schema
for developer, does not for marketing).
MAJOR changes is backward incompatible and require changing
project name, path to files, GUIDs, etc.
MINOR changes is backward compatible. Mark introduction of new
features.
REV for security/bug fixes. Backward and forward compatible.
This versioning schema inspired by libtool versioning semantics and by articles:
http://www106.pair.com/rhp/parallel.html
NOTE: I also recommend provide build/date/custom/quality as additional info (build
number, build date, customer name, release quality):
Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545
But this info is not versioning info!!
You can use any form of version numbering you desire.
I just recommend using something that makes sense. The Major.Minor.Revision numbering is popular, but any numbering scheme you wish is "valid".
When developing software libraries, I recommend using the version number to communicate the level of source and binary compatibility between two releases.
Since you're developing a web application, a two part version number is probably sufficient. The first part is for new functionality and the second is for fixes.
Our application is quite mature, and thus we are up to version 16. However, this can give the impression that the software is old and out of touch (how many commercial applications are there with a version 20+??)
Obviously, version numbers are quite arbitrary - what do other people use? I quite like the Ubuntu approach of month.date, but I'd like to see what other strategies people use.
We tend to go with something like 1.20.5, where the 20 is, in your case, the fairly high 'release' number or something.
When we completely re-write a product in a different implementation, it becomes 2.0.0, and so on.
It also means that the beta versions can be 0.2.3, for example.
I think it's pretty standard to use a sub-version format like 1.1 or 1.1.2 or something to that effect for just bug fix releases, minor additions, etc... and then plan to increment the main version number on major releases.
My company develops product for 19 years, and we have only version - 3. Although we had 1.2, 1.5 and so on. I think this is the best practice.
We use Microsoft's system (or at least their documented system - real binaries seem to be rather less consistent):
Major version (incremented on breaking or large changes)
Minor version (incremented on non-breaking or small changes)
Revision number (incremented on each service pack release)
Build number (incremented on each physical build)
Whenever a version part is changed, all parts below it are reset to zero rather than just changing independently.
As Christian said, we used major/minor numbers along with month-date for release.
For internal usage, we use CVS's date.
In our case, product is fairly small, we refer with md5sum when talking to QA folks.
Version numbers can be used to sell upgrades to non-technical people either from the perspective of the software vendor wanting to get people off old versions or the user trying to get management approval to upgrade.
If you were to say that you are using "Version 20" this doesn't immediately mean anything to everyone.
If you say that you are using "Product X 2005" everyone understands that it's a 4 year old product.
(Technical people probably don't care either way!)