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.
Related
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
I have an old application that I manage that runs on top of a progress database. I'm trying to gather some information, for various reasons. At a minimum, I need to know when Progress 9.1 and 9.1D were released. I mention these two versions because we are using 9.1D and, I assume, the "D" revision is probably just the fourth iteration in miner updates since the initial release of 9.1.
Optimally, I'd like to find a source-link to a Progress DB change log. However, questions for documentation aren't typically acceptable around here. Instead, I'm asking for the date these versions were released and requesting that you provide a source that I can explore further.
9.1A was 1999, 9.1D was 2002.
9.1E SP04, the very last release of version 9, was released in 2004.
With version 10 the product name changed to "OpenEdge". Which is much easier to google than "progress" ;)
If you actually have a given release of Progress installed you can look in the "version" file. It will tell you what the build date was.
For a general idea: http://www.oehive.org/VersionHistory
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.
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.