This is a series of posts on the problems and processes occurring when the new version of a software product has to be released with the support for an upcoming operating system, but when the operating system has not been released. In the first post in this series (Getting updated seeds for a new operating system – Part 1), I talked about some of the challenges that occur in this scenario, and yet how important it is to ensure that your software application is certified as working on this upcoming operating system. In this post, I will talk more about seeds of the upcoming operating system, something that I finished the previous post with.
Seeds are one of the most critical instruments in terms of ensuring support with a new operating system. Seeds are what the makers of an operating system send to their partners during the development phase of the operating system. The expected high level approach is to test with these seeds as and when they are received, file for defects (while also tracking whether those defects were also present in the previous version of the operating system), and then track these defects so that you have fixes. There are many areas that need to be worked out with respect to these seeds and the process of using them. Here are some of them:
– If you are part of a large organization, then there would be a specific person within the organization who would be receiving these seeds. For Microsoft, you might be thinking that such seeds would be available with a MSDN certificate, but many times the seeds are provided to specific partners quicker than they are provided through the MSDN download. Your team would need to ensure that they have done the required processes to get information about the availability of the seeds and have the required permissions.
– If your product is available on multiple languages (and 32 / 64 bit versions), then you need to ensure that you have done the processes / passed on the required information so that all these seeds are available. We one ran into a crisis when some of the seeds for European languages were available with a delay, and there were already schedule issues with regard to trying to support an operating system that would be released a couple of months after the release of our product.
– If there are permissions required for your vendors, please ensure that you have applied for these and got them. It is one of the modern practices that there is a lot of testing or language work that is done by vendors (and their environments would typically be the same as that of your teams) and the
seeds required by them are the same as your team. However, in most cases, the makers of operating systems have legal arrangements that need to be executed by those who are selected to receive their seeds and your vendors might be counted as a separate legal entity. In such cases, it can become quite expensive and pose many challenges if your vendors do not have such an approval. You should ensure that such approvals are available before the date by which you expect to get these seeds. In one case recounted by a colleague, the approvals were late because they were applied for late, and because of a tight schedule, the vendors were asked to be present in the company office rather than at their sites. This was expensive and a logistical challenge, which meant that senior management was very unhappy and made their unhappiness apparent.
Read more about this in the next post (Getting updated seeds of new operating systems – Part 3 – TBD).