For those that use the scrivener 3 beta

[Bethin2301]

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.

[Tom Lewis]

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.

[devinganger]

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.

[kewms]

To be precise:

The new official release will be most likely out within a month with a list of known bugs. You can use the latest Beta till then.

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.

viewtopic.php?f=57&t=60279

Katherine

[Ati2]

"with a list of knows bugs"

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

[kewms]

"with a list of knows bugs"

Errr, say again? 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

[SkyPilot]

"with a list of knows bugs"

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

What Katherine said.

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

[Ati2]

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.

How about fix all the bugs and release it soon?

[devinganger]

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.

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."

[kewms]

How about fix all the bugs and release it soon?

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

Katherine

[Ati2]

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

Only if it doesn't delay the release.

[Amcmo]

How about fix all the bugs and release it soon?

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.

[SkyPilot]

How about fix all the bugs and release it soon?

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.

[Ati2]

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!

[SkyPilot]

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.

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