Tag Info

New answers tagged

0

Look at what will happen... Option 1 will generate support calls when users install the wrong version. There will always be one user who either can't read or pick the latest version thinking they know better... and you'll have a large number of versions to potentially backport fixes to should you need to. Option 2 adds some complexity to the UI code, how ...


0

I've dealt with this in a slightly different context, but what we came up with was that if you used our public server we required you to upgrade. If you self hosted, we allowed you to stay on whatever version you liked. I know that isn't the most customer friendly answer, and it might not be an option depending on your situation, but it was the stance we ...


0

API versioning is fine but this would require more some work at the UI Layer a) The UI needs to know which version of the API to invoke depending upon the configuration ( use a properties file or a resource file on the client device) b) Also the server needs to have support for multiple versions of the API's. Does the server API only cater to Mobile ...


2

My preferred method which I have been using for at least a few years now is to bump up the number after each story is completed. This means that the versions released at the end of the sprint will not be continuous, e.g. after 1.2.3 you might find 1.5.2 rather than 1.4.0. In the changelog you may either list the intermediate versions with their ...


2

If the classic semantic versioning scheme "MAJOR.MINOR.PATCH" makes sense, depends on to whom you deploy, and especially when and how often you deploy to the end user. The scheme is most useful if you work with stable release "4.5", where you start with as 4.5.0. The versions 4.5.1, 4.5.2, and so on contain only bug fixes, whilst you internally already work ...


5

For typical release management, you will want a build number being generated by your build system so that the DLLs are versioned every time they are deployed. This will ensure you can later check which version is deployed on a given server. Your 'marketing' version, which is usually put in release notes or published to your site should not be updated each ...


2

I would use build numbers. Usually a build number would correspond to the highest version of the version control system. If mondays build number was 1745 and there has been checked 5 changes in during tuesday, tuesday evenings build number would be 1750. Then make a short summary for what has changed between 1745 and 1750. Then every time you update the ...


7

Yes. It is good practice to keep most of the version number in vcs. If we consider semantic versioning semver.org where we have major.minor.patch.build the first three must live in vcs. The last one can be a incrementing number from your build server used to backtrack the specific commit that a binary is made from. To facilitate this in .NET we have made a ...


22

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...



Top 50 recent answers are included