Developers in the augmented reality space are sitting on the bleeding edge of a hot technology. With the intense interest, especially in the tech circles, there are a large number of people working on potential solutions and uses for the technology. There is also a lot of time, money and effort being put in the tools and infrastructure for the technology. For better of for worse this also means constant changes.
The primary software SDK for the Microsoft HoloLens, known as the HoloToolkit and HoloToolkit-Unity, has gone through a major re-visioning as well as renaming. Now know as the MixedRealityToolkit and MixedRealityToolkit-Unity Microsoft has begun adding in the tools needed to get the new Mixed Reality head-mounted displays working.
Along with this major update, Microsoft has also released a bit of a roadmap for both the Master branch and the Windows Mixed Reality branch labeled DevUnity2017.2.0. Microsoft's goal, according to the roadmap, is to line up the major updates with the release of new major versions of Unity.
There is always a level of risk involved with updates, especially when we are talking about a medium to large project. In most cases, you will have the software and SDK versions locked down past a certain point. This is designed to avoid major breaking changes and creating weeks of potential work. Having a roadmap, even a basic one with a little detail, is great for allowing project manager's to better plan out when to jump into the new updates or when to lock the project. Being able to, at least more accurately, calculate the potential new features, against the risk of time lost fixing new bugs.
The problem with being on the bleeding edge is sometimes you are the one bleeding. This is especially true if you are working with beta software instead of tested releases. Here are a few pointers to make these changes without too much pain.
- Read through the feature list to determine if the added functionality is worth the risk of a day of downtime or other problems.
- Plan your updates.
- If you are a community driven developer that wants to help lay the path for others, make sure you are doing your early release work with a separate code base, to help avoid serious down time.
- Source Control is your friend.
- A separate computer, or separate login, for beta software testing can go a long way. To some, a whole computer dedicated to testing beta updates is overkill for sure. If you have it use it.
I am a big fan of the new and shiny things, so I am typically jumping head first into the new releases or beta software. Yes, often I get to see the new features and incorporate them before others, but I also get cut a lot. It helps that I have a large number of computers in the office.