Talk about the app version number problem

Title: Talk about the app version number problem

Why to talk about this problem, Friday night 11~12 Point, was named, said the app is wrong, invalid version number, the mall can not order.
I was getting ready to pack my things and go back to my hometown on weekends, so I saw this problem and Daisy was tight.
I wipe, I just added the version number check, in addition to the version number check, I also with the statistics sister carefully check the last six months all the version number, how can still have problems.
Hurriedly check, the original result, saw a g1_2.5.5_65, in my repeated questioning said this is 2.5.5 version number.
Then let's talk about why we have to add a version number check, and then again, why the problem is added, and finally discuss the version number rules.
It is quite reasonable to discuss how the parameters of version can be transmitted.

First in the app release process, because the new version of the new features, some need to be compatible with the old version, so it is very likely that the server needs to know the version number of the app,
and the server in the upgrade service and its own API must also have the concept of version number, although many times we may not notice, but the version number this must be both sides of the existence of each other.
I am in this scenario, our new functionality needs to be compatible with the new old app, so the server needs to know the version number of all apps, which is the parameter that needs to be passed to the service by the app.
At the same time the server also needs to be based on a version number such as 2.8.5 make version number of the judgment.
For example, the version number is less than 2.8.5, then it is the old logic, and the version greater than or equal to 2.8.5 is the new logic. This is probably the simplest compatible logic based on the version number.

To here, the reader must have seen why the addition of a version number will also add problems, this is the addition of a version number check also added to the cause of the problem.
Before I add the check, not sure of our version number of the rules, and then I find statistics sister carefully statistics of nearly half a year of all the version number, the result is that our version number is x.x.x such a number,
x must be a number, so it seems that there is no problem, I follow this rule to parse the comparison, the result when encountered above see g1_2.5.5_65 This version number, direct numberformatexception.
Fortunately, our handling is very decisive, in the version check out any exception, all prompt the user version is too low, let the user upgrade.
But also exposed a lot of our problems, our app after more than two years of the distribution has never been unified version number, even the rules have not been unified.
Ask again, said because of different download channels and push channel, we will write a different version number, the result of this answer I am not satisfied.
Heart is helpless also no way, so push version number hurriedly unified, at least in the rule can have a unified analytic rules.
One of the things we do well here is that at least we have the version number, and at least the app was passed, regardless of the version number that the server was using.
It should be noted that the version number of this thing can not be written freely, and can not be arbitrarily planned, this needs a unified planning, and the sooner the sooner the better planning.

So here is the third problem, the version number of the rule problem, on this issue, I do not want to delve into and research.
Baidu "Software development version number rules" or "software development version number naming specification" is very detailed, very clear, very easy to understand.
No matter what I want to say, whatever you do, you must specify a rule and specification that you can resolve uniformly, as long as the version number can be handled well according to the rules and specifications.
I recommend the use of the version number is two,
1 Yes: Major version number. minor version number. Revision number. Date Version number
2 Yes: Major version number. minor version number. Revision number. Build Version number
Such a set of numbers, clear, enough to use.

Finally talk about the version number how to transfer more appropriate, first we do not say the app, we do server-side development, especially RESTAPI must have encountered a version of the API to say,
Different people on the Internet have different views, different sites have different ways of implementation, I say I know the common several ways:
1. Pass in HTTP header, for example: Header.set ("Version", "2.8.5")
2, in the way of using URL path, for example:/www.xxx.com/order/v2.8.5/create
3, using the URL query paramter way to pass, for example:/www.xxx.com/order/create?v=2.8.5
4. Use form form to submit version, (this seems extremely rare) For example: <form method= "Post|get" action= "/order/create" >After this understanding, then the app to the server to pass the parameters, there are no outside of these ways, the specific use of which in the way can be based on their preferences.
It seems that I have seen in an article that although the way of using URL path is more intuitive, some large sites are also used, but the restful specification to use version in the header is considered orthodox.
This does not matter, I feel all right, before the eldest brother and I had a quarrel with this, I said to add in the URL path is the second way, the result of the boss disagree, said that you will maintain a bunch of url,v1,v2 in the future would be very troublesome.
Say recommended the first, I am more stubborn in the second way to do, and then another colleague also discussed this matter, the second way is better, the attitude of the boss here has changed, say what what the company is the second kind, we also the second kind of bar,
My heart that grievance, special, I told you, you and I also contend for a yarn, I do all do, still sprinkle salt on my wounds. I contend with the eldest brother this is not the future can not do the boss, sad urge.
Now think of the third kind is also very good, really very good.

All right, today, let's talk about the version number.

You are welcome to comment or ask questions.

Talk about the app version number problem