You won’t regret it. At least not much… =}
Congratulations, You won’t regret it.
As part of the discussion above - sorry I did not read everything - is about the time between a current Release (V7) and a new (WIP/V8) comming soon:
What I don’t like is, that it looks like V7 does not get any, or at least only a few Bug-Fixes.
And I am talking about Bug fixes like the following 2 - not about new Features.
(1) super annoying: mac command line not scrolling (Release-target V8.1)
(2) or a quite simple unsymmetrical MeshSphere - that got fixed very fast (Thanks) but for V8 (why?), not V7.
If people have to pay for the V7 until the day before V8 is released - ( I can accept that policy) - the bug fixes should be in the current release (V7).
I agree. Fixes should not be considered as new features
Regarding back porting bug fixes, fixing a bug always has the risk of breaking other things. Many fixes have been back ported to v7 nonetheless, but not all of them are feasible.
V7 went BETA in September 2020 and then was released December of the same year. Looks like you might be buying yourself an early xmas gift.
We shipped 33 service releases over 3 years for Rhino 7 so far, with 2,500 bug fixes. Is that what you mean?
out of curiosity 2500 attended how many left over?
That’s not an easy number for us to compute. The items in our bug tracking system are a large mix of both bugs and feature requests. We don’t have them well distinguished from each other. There are also many older bugs in the system that probably don’t exist anymore (one off issues for a single user, operating system changes over the years, they were fixed by some other bugfix at some point in time) and of course there are bugs that haven’t been reported yet.
Currently there are over 5,000 items responding to state=open under Rhino in youtrack. Of course, most of these are now labeled either 8.x or Future. Items could be bugs, usability issues or feature requests. They could range from 5 minute quick fixes to months-long existing function re-writes to completely new features.
As far as I understand, at a certain point many months ago it was decided that it was more important to concentrate on developing V8 towards release rather than fixing outstanding items (“bugs”) in V7, so only critical broken stuff (like crash bugs) are being worked on for V7.
There are plenty of other items flagged as private that you can’t see. This is because they may include sensitive data such as models or contact information.
What I can’t see doesn’t exist…
Good point; nevermind
“We’re not adding any new features, nor are we making significant changes to the UI. We’re also done breaking the APIs…”
“Please report bugs that are regressions from Rhino 7, serious workflow issues, or problems with new features that you think make them unfit for release.”
Is this a meme? WIP/Beta is far from usable and you are nearing the release?
Our current thoughts are:
“Should we buy Rhino 8, just to support the developers, to then continue use Rhino 7?”
Personally, all the feature that are long expected years ago, that are missing from Rhino 8, once you go release, I understand I’ll have to wait again years to start hoping them being fixed/added.
No, you should buy Rhino 8 if it has stuff that you consider worth the price of the upgrade spread out over the next three years or so. If the upgrade is 400$/€ (during the special intro offer) and 3 years is around 675 working days (minimum) then it costs a maximum of 60 cents a working day.
If that’s not worth it for you, nobody requires you to upgrade…
You didn’t understand OR I explained myself bad (sorry).
We WANT to support Rhino development!
Because we need fixes for Rhino 7 (or even 6 (or even 5)) features and need them to complete the half-way situation of many others that currently are absolutely not ready for work.
Guys, so pessimistic?
A lot can happen in 3 months, which will be used for fixes only, since it’s feature freeze.
Second, look at the competition! Even if Rhino’s not a perfect piece of software, and never will or can be, and even if R8 is not as stable as it could be, it’s one of a kind in a software world dominated by commercial interests more than anything.
These 400 bucks for 3 years of work… I almost consider it as a donation, to keep the show running and Rhino on my PC.
Well not really what I mean. What I mean mostly has to do with the video game industry and how it’s evolved.
Basically, now a days, you buy a game which is released prematurely(incomplete), and over time the game will be updated.
At the end of a 5 yr period, a user might have to do hundreds of gigabytes of updates and the game will be extremely improved and contain vast amounts of content more than the initial release.
So, the point here is mostly about the ability for “software” to be updated over time – post release.
So you “shipped” 33 “service releases”/3yrs, 2500 bug fixes etc., so my question would be how many gigabytes of data is the initial release? and how many gigabytes of data in “updates” were there in 3 yrs?
So it sounds like we need to add 500MB of textures with each service release? Soon we will have 200GB of additional bulk, and it will be worth the price of the upgrade?
I’m kidding - it seems like the metric based on file size is really appropriate for video game content, but not so much when you’re making the content. I’m guessing that ShrinkWrap added less than 20MB to the size of Rhino, which by the bulk metric above means we should probably just leave it out.
The bug fixes might only add a few KB. And in many cases, we actually make Rhino smaller by removing code that doesn’t work.
To echo Helvetosaur, we really only want you to buy Rhino when there’s something in it that you value, need, and are delighted to pay for. If Rhino 8 doesn’t have that, please keep your money.
We can’t prioritize everything for everyone all the time. So the things we prioritize will delight some and disappoint others. That’s just a reality. I’m sorry to those who get disappointed over and over and over again.