I’m reaching out to gather insights about the recent updates in Rhino 8 Like many users, I’ve noticed a less than satisfying experience with the initial release of Rhino 8. However, I’ve read that versions 8.4 and 8.5 are expected to bring significant improvements, addressing issues such as bugs, crashes, plugin compatibility, and enhancements in the scripting editor, like loading external Python libraries.
My questions are as follows:
Versioning System and Roadmap: How is the versioning system in Rhino 8 structured? What defines the leap from 8.2 to 8.3, and then to 8.4, etc.? Is there a detailed roadmap available that outlines the specific improvements and fixes that each sub-version brings?
Migration Timing: Given the improvements in the pipeline, when would it be safe or advisable to migrate to the latest version? Are there particular milestones or versions that we should be waiting for to ensure a smoother experience?
Naming Conventions: Considering the initial challenges with Rhino 8, why opt for naming conventions like 8.3, 8.4, etc., instead of starting with 8.0.1 and so forth? The chosen naming now suggest as stable release with major updates rather than it seems now, in pre-release version with still many bug fixes and needed improvements (not a criticism, merely asking as non-developer what is the ‘rationale’ behind this). How does this reflect the development and release strategy?
User Testing and Feedback: There is a sentiment in the community that early adopters are more like ‘user testers’ finding bugs. How is user feedback from these experiences being integrated into the development process?
I believe that understanding these aspects can help us, as a community, to better plan our workflows and decide when to adopt newer versions. Any insights from fellow users and the McNeel team would be greatly appreciated.
8.0 (7.0, 6.0) are the first release of the new major version. Any number increase after the dot is the next service release, 8.1 was the first service release, 8.2 the second and so on.
Service releases are released on a monthly bases, typically the second Tuesday of the month, along with the Service Release Candidate for the one that will be next month. Service release candidates are typically only for stabilizing - fixing major crashes and such, although sometimes this rule is broken.
Each service release is free for those who have a valid Rhino 8 license. Upgrade licenses are required only for major releases (the first number, so next one will be Rhino 9).
User feedback is always listened to and integrated as much as possible. Software development is always a balancing act between competing visions, wishes etc.
Addendum, towards the end of a major release often the release schedule for service releases is relaxed as focus shifts fully towards the next major version. Rhino 6 had in total 35 service releases, Rhino 7 has also 35 or 36 service releases. For the first year or two you pretty much can assume that the minor number in the version is that many months after the initial 8.0 release.
ah, thanks. my assumptions was you were counting van 8.0 tot 8.9 and then 9.0. Never payed much attention to it, so that got me a bit worried
then again, if 8.0 is a major release, why is it then still advised to stick with 7 for production work? I understand unforeseen bug-fixes, but when do you tink we can safely migrate with a pretty streamline experience and enjoying all the nice improvements you’ve implemented? It seems to me (as a rhino user for over 25 years now) that in the past x.0 releases where pretty much ready from the start…although that could be related to me not testing it hard enough or spending too much time on this great forum obsorbing all the pro’s and cons
All initial releases have had their problems, maybe 7.0 was one of the better ones? I also think it may depend on who you ask.
I pretty much focus on Raytraced and Rhino Render, I can’t really talk outside of that too much. From that I’d say it’s better than in 7 in most aspects.
But know that if you upgrade to 8 you still have access to 7. And if you buy 8, you also could have still access to 7. I suppose it is up to you to decide whether the software is ready for your particular workflows or not.
I’m not associated with McNeel but have been using Rhino since V4. Service Release Candidates are usually released weekly, and, as Nathan mentioned, Service Releases are usually released monthly.
McNeel uses the YouTrack ticket system for tracking the status of software changes including as bug fixes and enahancements. Most YouTrack tickets can be viewed Rhino users. The McNeel folks usually provide a YouTrack ticket number when they open an issue such as RH-79780 . The entire list of public viewable issues is at https://mcneel.myjetbrains.com/youtrack/issues.
Remember, previous versions of Rhino can be left on the system and used after V8 is installed. I currently have V5, V6, V7 and V8 installed.
I believe that is the opinion of some users, but not a recommendation by McNeel.
My understanding is that was the intent with the release of Rhino 8.0, which had previously been available to users in WIP form for several years.
As has been mentioned, it greatly depends on your personal workflows if any given release of Rhino is something that you can work with.
I’ve taken a quick look at all your posts here on the forum and can’t find one where you’ve reported a problem in Rhino 8. Please let us know what you are running into specifically!
-wim
I have a license for 8, just waiting to end my current gh1/r7 project. Much looking forward to start this new chapter with GH2. I recall the excitment of using Explicit History back in 2007. Back in those days we were creatively using game engines tools to achieve what David made easy
I usually recommend buying upgrades when they are introduced and then start using them commercially after 6 months. That gives the customers time to test it out and the developers time to iron out the major bugs. (And never jump to a new version in the middle of a project)
PS! I also like the x.x.x numbering like other software use, but McNeel don’t introduce new features to the current version, that happens in the WIP of the next version. So it makes sense how they do it IMO.
i advice a quite similar strategy to customers / production.
in an educational context I do a different strategy, earlier adaptation - start using the Beta / or the first Release - whatever fit s to a new / starting semester.
I want the students to learn with the latest tools / interface etc…
