McNeel has this fantastic open beta system, wherein they allow their existing customers to start using the next version of Rhinoceros as soon as they start developing it. This gives customers the opportunity to offer feedback way early in the development cycle, as opposed to the end of the cycle when things are pretty much baked into the software and cannot be drastically changed untill the next release.
You can read all about McNeel’s new release process here. To sum it up, basically McNeel has three stages in their development cycle.
Phase 1 – Work-In-Progress: This is the pre Beta phase where the software is not production ready and new features are only prototyped. This stage can go on for 6 months. Rhino 5.0 is currently in this stage.
Phase 2 – Beta: Once most of the new stuff is production ready they release a Beta, which customers may start using in their production environment. In case of other CAD vendors this is the stage when beta testers and third party developers first access the new version and start reporting problems.
Phase 3 – Release: This is the final software and is released only after Beta users tell them that is is fit to be released. That’s why McNeel does have a fixed time of the year when it releases a new version of Rhino. Service Releases then follow which sort out bugs and even contain new functionality being worked upon on Rhino Labs.
I am pretty sure McNeel’s customers like this approach. As a plug-in developer I think its fantastic. Usually we get access to new versions of CAD systems in the Beta stage, which is not a bad thing. We usually get enough time to port our plug-ins and test them on the new version. However, by the time the Beta release is out, most CAD vendors pretty much freeze enhancements to their API or limit major changes to it. So if there is a new feature and we would like greater control over it through the API, we most probably need to wait for the next version.
However, with McNeel’s approach of giving access to the new version at the WIP state itself, not only do customers get a chance to have their say in the new version, but even plug-in developers can start porting their plug-ins much earlier in the release cycle and have their requests for API changes granted in the release being currently developed.
For example, McNeel decided to add 64 bit support to Rhino 5.0. Not only can Rhino users immediately start using Rhino 5.0 WIP in a 64 bit environment, but plug-in developers like SYCODE can immediately port their Rhino plug-ins to 64 bit as well, which is precisely what we have been working on the last couple of weeks.
All our Rhino plug-ins have been ported to support Rhino 5.0 64 bit. I urge all our existing customers who are using the 64 bit versions of Rhino 5.0 WIP to try them out and report any issues. The links to the individual product pages are given below:
- Mesh To Solid for Rhino – Mesh to solid conversion plug-in
- MeshCAD for Rhino – Mesh modeling plug-in
- Point Cloud for Rhino – Reverse engineering plug-in
- TerrainCAD for Rhino – Terrain modeling plug-in
File Import Plug-ins
- ESRI Import for Rhino – ESRI Shape file import plug-in
- NC Import for Rhino – NC Program file import plug-in
- PLT Import for Rhino – HPGL Plot file import plug-in
- SAT Import for Rhino – ACIS SAT file import plug-in
- VTK Import for Rhino – Visualization Toolkit file import plug-in
File Export Plug-ins
- PLT Export for Rhino – HPGL Plot file export plug-in
- VTK Export for Rhino – Visualization Toolkit file export plug-in
If you encounter any problems, please create a support ticket at the SYCODE Support Center. Support is free. After all you are helping us improve our software, right? Please don’t get me started on CAD vendors that charge their paying customers to download service packs that contain bug fixes. I really want to end this post on a positive note.