For those that use the scrivener 3 beta

Does it seem like the full version will be ready soon? I’ve been trying to pay attention but I struggle to “understand” the patch notes and can’t seem to tell if we’re any closer to getting it than we were three months ago. This is not a complaint to the team or anything, it’s my own fault that I can’t keep track. So hoping someone a bit more savvy can chime in.

Tiho posted yesterday that it will be released within a month, and that the current beta 35 will work until then.

NO. That is NOT WHAT HE SAID. Nobody wants to go through this again, so please transmit what the devs say ACCURATELY.

He said they EXPECT IT in the next month. That is NOT a promise from L&L that it will be available by a certain date. If they uncover a big enough flaw or set of flaws to push it back, then they push it back. If that pushes it back past the expiration date of currently available beta versions, then based on past behavior they will need to push out another beta release to test the fixes and it will still be available to use.

Using a beta comes with risks. Using a newly released production version comes with risks. If you don’t have the time or energy to keep up with updates and bug fixes, use the current release version and wait until the first couple of patches come out for the released version. There will be some churn as bugs are identified and fixed.

To be precise:

The key words in that statement are “most likely” and “within a month.”

Most likely = we don’t expect showstopper bugs, but this is not a guarantee.

Within a month = 30 calendar days, NOT end of January. Particularly since the post was made on January 20. If he meant end of January he would have said so.

Also “latest Beta” does NOT necessarily mean Beta 35, which expires January 31.

Katherine

“with a list of knows bugs”

Errr, say again? :smiley: Why not fix the known bugs before releasing a version that should be stable and bug-free?

There’s no such thing as bug-free software.

FWIW, other users have been taking the exact opposite position for months, literally begging (or demanding) for a release version sooner, rather than later, bugs or no bugs.

Katherine

What Katherine said. :smiley:

I’ve been involved in beta testing for years prior, both public and private. Because bugs are always being found during the life of software, releasing a “perfect” app is impossible.

That being said, the life of the beta is to find, test for, and fix the bugs, big and small, that come to light. But, at some point, the app is typically “frozen” and published with a list of remaining known bugs, usually mostly of a minor or less severe nature. Revisions and updates then often follow rather quickly, fixing those bugs that simply could not be addressed prior to the official release. And, there are many reasons why an official release needs to happen by a particular date, ranging from programmer availability, upcoming products, or work on already released products.

I’ve been involved in betas, where the test/fix/pre-release period was as short as 4-5 months. In those cases, however, an Alpha testing period might have been underway for a year or more. My sense of L&L is that the extended beta is not only because of the complexity of the program, but because the pressure to meet some arbitrary marketing/sales date is not there. Taking a lengthy time with this Win 3.0 beta says a lot about the dedication to get it as right as possible. Although I don’t do a lot of testing and bug hunting any longer, I’m just pleased that we’ve been able to work alongside in a public beta, hopefully helping craft the course, direction, and capability of what is shaping up to be a very fine new version.

JMHO. YMMV :stuck_out_tongue:

Sure, bugs that have not been caught before will surely pop up when a bigger audience starts using it. But when you know the software is not woirking properly, and release it anyway, that’s a different story.

I’ve been waiting for the release since last summer, so I’m definitely one of the people who wants to see it done. Yet, releasing it when you know it’s not working as expected, seems a bit unprofessional. Which, I imagine, is not what L&L needs after missing the release deadline so many times.

Don’t take this as a complaint, though. :slight_smile:

How about fix all the bugs and release it soon? :smiley:

It’s a common practice in the software industry. Not all bugs are created equal. Some are easy to identify and equally easy to fix. Some are easy to identify but fixing requires deep fixes that touch a lot of code and require a lot of testing to make sure you don’t introduce new bugs along the way. Some bugs are hard to identify, but you can at least figure out workarounds (or conditions to avoid that trigger the bug). Some bugs dovetail into an area of the code that you’re already planning on touching in a later revision, so going in and potentially destabilizing that area of code isn’t a smart thing to do when you’re going to be redoing larger chunks anyway. And that’s not even including the factors of severity, scope, and potential audience.

Managing releases is risk management – you identify and triage known bugs. You try to get all of the severe ones, but sometimes you can’t right away. So you put out a list of known issues at a release, and then you get to work on the next revision – where some of those known issues are going to get fixed, now that you have a usable and stable release for your customers to upgrade to. You can’t make it perfect. You can make it “good enough.”

Would you like a unicorn, while we’re at it?

Katherine

Only if it doesn’t delay the release. :smiley:

Apple, Google, MS with far greater resources than L&L release operating systems with known bugs. We just hope they fix the ‘oh my god’ ones before they do so.

Yep, and I can tell you from experience, that between the moment the decision is made to launch a “final” release…the final version files are frozen…the mirroring of the development files onto the distribution server is done…the initial downloads of the final product files by the user base, and sunset of that first day, there may be a few hundred “bugs” or…er…undocumented features, that will be found and have to go into the queue for a v3.0.1 release a few days or weeks down the road. That’s just the way it is.

I’m sometimes extremely nostalgic for the pre-Internet days when you couldn’t send out a patch when something didn’t work. You had to make it right the first time.

These days, even cars get patches for known bugs after their release. “Sorry, we made some errors, and it might explode. Bring it in and we’ll fix it for you.”

I guess any bugs in a writing software can’t be as bad as exploding cars, so bring it on! :smiley:

LOL…yep, sure makes you appreciate what went into the computers to land two guys on the moon in 1969. But, there were probably only a couple of dozen lines of code in the on-board computers, which were likely the size of a refrigerator. (Sorry, no long-distance updates possible).

Heck, I’m old enough to have been there with my mouth hanging open when Pong was big. I had an IBM clone that set me back two grand, and I commanded its every move with DOS…and, thought I was in heaven. And, as a Fortran programmer on a VW Bus-sized CDC 6400, I was pretty certain I could remotely land a vehicle on Mars. :smiley:

All to point out a huge appreciation for what goes into Scrivener, and all of its capabilities. Two thumbs way up!

Yes, they went to space expecting bugs. “Hand-calculated” meant using log and trig tables (in paper books), plus slide rule, pen and paper.

Sorry to burst your bubble but pre-internet days very buggy software (and systems) were delivered. It was pretty much ‘stiff s…’ until a follow up tape/cd/rom or other component was made available.

I vividly remember having an 8086 based system that had issues from the factory and the fix was to cut a track and solder an insulated wire between that track and another point on the board. That was in the days of hand tape board designs so a fix could take months.

First copies of visicalc, 123, multicalc, word perfect had so many bugs they were painful.sucks big time when a spreadsheet gives incorrect answers to a complex calc.

All this is to say the ‘known bugs’ is, was, will always be a part of complex software development.

“If you believe in me”, said the unicorn, “I’ll believe in you…” :slight_smile:

I love unicorns! I’d love for you all to get me one. But I’ll probably settle for the awesome new v.3 when it’s as done as it can be for a release in, I hope, the near future. Looking forward to it! :smiley:

Well, I remember when the “all new and shiny” subway cars in my native Stockholm arrived about 20 years ago which ended up with both physical and software related problems delayed the entire thing (despite major festivities with a lot of media and stuff looking on as the entire system crashed and burned in front of everyone who were there for the party but ended up following the horrific premiere as it embarrased everyone involved in it hysterically). Lovely times.

I also remember many other such situations during the years I’ve lived, and of course know of other such stories before I could witness them myself.

Some of the bad stuff includes the OS we are all working on, Windows (I gather, because we are all desperately discussing the Windows version of Scrivener here, after all). Like releasing upgrades to Windows 10 that ends up totally erasing decades of photos, personal letters, written down stories and memories, company information and other stuff for thousands upon thousands of people. Or crashing other very critical functionality at other times.

There hasn’t been an upgrade to Windows 10 for several years now that hasn’t been accompanied by severe warnings saying that you really shouldn’t download and install the updates just yet… Warnings issued by Microsoft themselves.

Other software I have encountered include Antivirus software that totally locked me out of my own computer for absolutely no reason at all. Or graphics drivers that totally crashed the entire OS because of a strange bug that no one at the GPU manufacturer had even predicted or seen at all. Which happened while installing a big upgrade to those newer generation drivers that would compare pretty much fully with the now planned upgrade of the software version of Scrivener from 1.xx to 3.xx.

Can you imagine how pissed I was when I learned that the bug in the Antivirus software was well known and had existed for years?

Can you imagine how equally pissed and sad I’d have been if the GPU manufacturer had known at all about the strange bug in the generation of software that turned my computer more or less autistic and locked into itself - so severely that i almost couldn’t even save the motherboard, because the bios itself was effected. They didn’t know. But I wish they had known, early enough that they might have been able to fix the thing before the big upgrade went live.

I could go on. Let’s.

There have actually been some horrible situations that might meassure in the same league even for software that released before the internet was as widespread a thing as well. This includes pc games as well, by the way. Or business software in the banking and finance industries. Very complicated when such things happen. Very nasty.

Also… as someone said just shortly before myself here in this thread, the NASA space program had massive software bugs (combined with computers that weren’t capable of handling all the data that was pushed towards them during operations), and so on. Massive stuff. But they did find solutions in most cases, thankfully, while they did update the software and also hardware between missions. Naturally.

And in the same spirit, there have always been incremental updates to software on disks and cd’s before the internet era, as well. Patch here, patch there. New version this or that, upgrade disk here and patch disk there. Lots of those things. I remember them all too well. Sure you don’t too?

Another thing that comes to mind, as we talk about early releases despite massive bugs… Anyone following the sad and heartbreaking result of the crashes of a major aircraft manufacturers latest model, where the new bestseller plane was released with new software that - apparently - had well known bugs that the manufacturer decided to just brush over? The cost of being sloppy and not caring about those bugs turned into a true nightmare, after all.

A few months or a year or two of fixing that software, combined with actually telling the airlines and pilots who were supposed to operate the machines that there was now such a software to begin with (and maybe that it might be a bit less stable than preferred in some situations) might have gone a long way to save lives. A new software that hadn’t existed in the previous models, that was buggy as nothing else… but the manufacturer didn’t want delays, nor having to deal with the costs of having to teach pilots how to handle that unfinished software. So… what happened?

Now, granted, a software for writing books and stuff ain’t a massive airplane that might lead to extensive losses of life if it crashes. But for many people within our creative community of writers, losing a lot of work and ideas and plot points that took, in some cases, ages for us to produce would still feel somewhat like if something crashed and destroyed our entire home and took parts of our souls with it.

Perhaps we should actually just try to learn from history (both recent and less so) and try to realize that releasing software is always (and will most likely always be) a story about having to judge the state of the product your releasing and deciding if the bugs and less than perfect functionality here and there might risk ending up in a plane crash or if the thing is actually good enough for now. With the promise of fixing remaining and future stuff later on, and as quickly as humanly possible, of course.

I know I prefer to not see my stories and those parts of my heart, soul and person that I “bleed” onto this virtual paper go up in smoke because the software I use had a big, big flaw that wasn’t addressed in time for the big release - perhaps because it was smoothed over or because someone decided that “what the heck, the clock is ticking and I just don’t care about it”.

Oh, we love them bugs, don’t we? Or we actually don’t very much, to be honest. Right? But they are there, and they will always be there.

If all the big devastating stuff and pretty much all of the annoying things are gone, and there is just a tiny thing or two that is actually easy to work around, then the software is (by any industry standard) actually ready to release.
If there are big horrible monster bugs left, or annoying stuff that threatens our work and all that we create, or any other part of our systems… then not so much.

It’s that easy.

And nothing has changed on that front during the… what… more than 170 years or so since the first embryos of what we today call computers were constructed. Nothing at all has changed. And I think Babbage, Lovelace and all of them other geniuses would probably agree with that as well.

Best. Retort. Ever.