Timeline for Deploying Multiple Versions in One App Package
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 25, 2019 at 20:05 | comment | added | Christian Findlay | A classic case would be SQL Server manager. You can run SQL server manager 2016 against a 2005 database server. The client is backwards compatible with ant server. The only way I can think of that that would work is if every client version is deployed in the installer. | |
| Feb 25, 2019 at 20:01 | comment | added | Christian Findlay | Sorry but that's a bit vague. That's not really the problem that I'm tasked with dealing with. In this case a client will always be on the latest version, but the back end could be on any version. For example, the back end could be on 1.3.0. The client might be on 6.5.7. They have to work together. I don't understand how semantic versioning solves this problem. | |
| Feb 25, 2019 at 11:43 | comment | added | Hans-Martin Mosner | The main purpose of semantic versioning is to be aware of the possible effects that a version number change can have. The point isn't to maintain disparate compatible versions but to switch to a new version for example on the backend without having to fear incompatibility with older clients (as long as they work with a major version supported by the backend) | |
| Feb 25, 2019 at 11:01 | comment | added | Christian Findlay | I mean as long as they're the same major version. Is that the point of semantic versioning? | |
| Feb 25, 2019 at 11:00 | comment | added | Christian Findlay | So in short, are you recommending making two disparate versions compatible with each other? | |
| Feb 25, 2019 at 10:01 | history | answered | Hans-Martin Mosner | CC BY-SA 4.0 |