what's your strategy to increase build number?
Most software has a hierarchy of version numbers:
The "marketing" version number (like "Windows 7")
The major version number - usually incremented when there's a major new version that breaks some compatibility with a previous version, adds a major new capability, requires purchasing an upgrade, or more.
The minor version number - upgraded every time there's a bug-fix or minor feature enhancement that's released to the public
The build number - this should be incremented every time any change is made to the program, so that if someone finds a problem in a nightly build or beta-test version, you can identify exactly which version was being tested. This number is often a revision number directly from your version control system like Subversion, or a timestamp, or something similar that makes it easy for you to roll back the code to that version if necessary.
All the dlls must have the same version number for one release.
Build number consists of "MajorVersion.MinorVersion.BuildNumber.Revision", usually I keep the Revision Number to be 0. Only the first 3 numbers are changed.
For every nightly build, BuildNumber will be incremented automatically. I will manually increase majorversion and minorversion if the changes are sufficiently big.
Every checkin should be tagged a version, use the subversion current version as the part of the build exe version.
It's quite reasonable to increase the build number for just every build. This way testers can tell more exactly which build they find a bug in and when it is verified to be fixed.
We have a build number that's incremented on every build (formal or otherwise). We use a CruiseControl.NET labeller for this.
We have a version number that's incremented by hand only on formal releases, and we define that centrally in one of the CC.NET scripts, which are held in source control.
Like everyone says, increment the build number for every build. We set the major/minor numbers by hand when we do a branch, a branch is usually done a few weeks before release, then that branch gets regression tested. Builds done on the branch still get incremented though.
Related
I'm using Gitkraken's gitflow:
https://support.gitkraken.com/repositories/git-flow
My fix basically requires changing a single HTML file, a class on a single element. I also want to change the version number in my app (it's a Windows store app, changing the package.appxmanifest file from 4.1.2 to 4.1.3).
My intuition is to (a) start the Hotfix branch, (b) commit the HTML change, (c) another commit for the version change in the appxmanifest file, and then (d) finish the hotfix, merging it into Master and Develop. Is that correct? If not, what's the order of operations?
Most probably You've found the answer during this time, but in case someone else finds this page then this answer might be helpful:
If this is an urgent fix for critical, out-of-cycle releases into production as Hotfix stands for, then yes, this is correct order.
In case it's a fix that can wait for future release then this should be handled as regular development and next order should be used: feature->develop->release->master
Why does Flyway use version numbers rather than timestamps?
How is that supposed to work with larger and possibly distributed teams?
Do I have to send and e-mail to all team members announcing that I am now reserving version number xy for me?
What happens if two developers both use the same version number?
What if a lower version number is checked into version control (and executed by the build server on the integration database) after another higher number has already been checked in?
I am used to mybatis-migrations that is closely modeled after the migrations in rails (>=2.1) where timestamps are used instead of version numbers.
Right now I think timestamps make a lot more sense: I don't have to worry about version numbers and out of order migrations are easily detected.
Quite a few questions here. I'll do my best to answer them.
Flyway's versioning system is flexible. It doesn't care whether your version is called 1.0, 20120816115123 or 2012.8.16.11.51.23. You are therefore free to use timestamps if you wish.
Reserving a version number can be a simple as adding your name next to a number on a whiteboard, a sheet of paper or a wiki page.
Flyway will detect multiple migrations with the same version and report an error.
Out of order migration support is currently the #1 requested issue and will be included in the upcoming 1.8 release.
When we were using SVN, we'd always print at the footer of our pages: "Revision XXXX". I've been looking, but I can't figure out how to do the same thing with TFS. Can anyone offer some pointers?
In case this matters: we're using ASP.NET MVC. I'm guessing it doesn't matter, however.
You can use the default version system for assemblies to track revisions number without adding anything in TFS.
If you use the Major.Minor.* format in your AssemblyInfo's AssemblyVersion attribute (e.g. [assembly: AssemblyVersion("1.0.*")]) it will generate a version according to the following format:
Major.Minor.Build.Revision
where
Major = Your value
Minor = Your value
Build = Number of days since
2000/01/01
Revision = (Number of seconds since midnight on the day
specified in Build) / 2
This will give you an always increasing number which gives you precise information on build date and time.
To use these values in your code, you can simply recover the version using Assembly.GetExecutingAssembly().GetName().Version.
You can update version number of projects in AssemblyInfo.cs using assembly versioning tools/techniques like this. Version number of an assembly can be updated based on TFS changeset number. Version number then can be displayed in application.
At least when it was released, TFS didn't allow symbol replacement in files which is what I think you're after. I'm not sure if that has changed in more recent versions.
Changeset != Version
That being said, you can add a setting in web.config that holds the version number, and display that on the page. The version number can be updated as part of the build process, but it will not correlate to a changeset.
I should probably add that this can become a circular problem. If you get the latest changeset number for a project, then add that to the config (as named above), then checkin, you are no longer displaying the latest changeset. Adding 1 to the latest changeset is not a guarantee either, because something can be checked in while you are updating the files.
We ended up using a MsBuild task that searches for a particular string and replaces with the appropriate value (not necessarily the revision number).
The task runs as part of our build templates and puts the revision number in all the files that have the token present.
We are approaching the initial release of a new product at our company, and I am trying to determine the best method of managing the versions of all of the different components and cross referencng those components with the marketing department version of our software. For various reasons, marketing has determined that the initial release of our product will be 10.1, however all of the components will initially start out at 1.0.0. Through normal bug fixes and patching and continued development work, the different components will no longer be at the same version number, so when marketing department decides it's time for version 10.2, it might contain 1.1.54, 1.2.32, 1.8.2, etc. Obviously, I could use a simple spreadsheet, but that isn't exactly the most user friendly method, and has issues for our tech support people to cross-reference the component versions (the customer is really only aware of version 10.1, 10.2, etc).
Is there a more "professional" method for this, or is a simple spreadsheet the best option?
The main principle I'd suggest is: Use the simplest scheme you can.
Consider making things easy for yourself, your marketing department, and your users.
When you do a release, increment the major/minor version number, and then stamp that across all your components. So in the 10.1 release, all your assemblies will have version numbers 10.1.xx.yy
Then if you really want to complicate matters with different versions within a release (e.g. for minor patches/updates, different customer variants, or just for internal daily or CI builds), then use the xx.yy fields. (In many cases you can get the compiler to automatically fill these two fields in with the date/time of compilation, for example).
This means you have a meaningful "marketing version" which is actually linked to your code versions (so you and marketing can talk about a particular release without any chance of confusion), and you can add extra information (e.g. build date) if (and only if) needed on the dev side.
edit: P.S. Even if a component doesn't change, rebuild it with the new version number. Trying to track a hundred out-of-sync version numbers is an avoidable nightmare.
At places where I've worked, we'd force the software version number to match the official, public (i.e. Marketing's) release number: if they wanted to ship "10.1" then that's what we'd set the software's version resource to, as part of the release build.
Why not leave all components at their "random" version numbers and create one super tag/label with the marketing version that encompasses all components? This allows you to keep updating the components in-between marketing builds and increment their build versions (without having to go to 10.1.001, 10.1.002 that may be visible to the customer) and also keep track of the marketing build. Also, what happens if you update some components for the next marketing build, but not others? Do you need to build those components just to update the version number?
Depending on your source control system, you should be able to easily create a release with a specified name/version that contains all of these components at different versions.
You should also just need to update one properties file with the marketing build number so it shows on all about screens, splash screens, tool bars, etc. If you don't have such a configuration in place, you may want to move to such a system. This allows for easy changes to the customer visible number while maintaining all component build numbers. Besides, what happens when marketing determines that the next version isn't going to be 10.2, but "Crimson?"
My organization builds a C++ application that runs on multiple operating systems.
Should the build number, visible to customer, be the same for a given state of the source code tree on all the platforms?
Yes, I think so.
One practice you can use is to use the changelist number or however your source control system identifies the checkin that your build system pulled to build your product. That way you always know what source you should pull to rebuild it as well.
There aren't any downsides that I can see. You want to be able to reproduce the build, so each should say what the build is. If it's the same build, it should be the same build number.
If you choose to (or cannot - from a build process point of view) not use the exact same versionnumber for builds made for different platforms, you should document exactly what your versionnumbers actually imply.
If you don't, typically a user of the software will treat the whole thing (e.g. 3.1.0.333 - where 333 would be the build number) as identifying a certain version of the software (thuse the code tree). If they use your software on differnt platforms, they then might think that 3.1.0.333 and 3.1.0.334 are actually refering differnt versions (as in code changes) of the product, which they might not.
The same is true for outher "build number" styles, like using some sort of date/time derived build-id.
If you globally manage your build numbers, you might consider adding a platform ID. So that you can build 3.1.0.333-x86 and 3.1.0.333-amd64 one after the other, but still have them share the same "number". It will also be more obvious to the user what the indent/meaning is.