I have a current license of v1.9 ( or whatever it is ) for windows, but I am nervous about putting an active project into it, because if there’s a gap between releases of the beta, and a gap between the betas and the full v3.0 release, then it means I have to go back to the old version in between … but unless I work on an active project, I am not going to get much testing done … so would it be possible to allow a license code to be entered into the betas, so that instead of timing out, they keep working, but just upgrade themselves to the next beta release once it is available, and then do the same between the last beta testing release and the stable v3.0 ??
This would be really handy so that I can just put my active project into the betas and work on it there, instead of just doing a very small amount of testing using the tutorial before going back to the stable release of v1.x … I am assuming you want as much feedback as possible, but the tutorial is a limited way of testing the beta, and I would do more testing if I could just be confident to put my whole project into it.
First of all, we can’t suggest working on anything in the betas that you’d be upset with losing. By their very nature betas are unpredictable and unstable, and while many of our beta testers have been quite happy to use them as a working product, we do urge caution.
As for moving between different beta releases- The reason each beta has an end date is so that all testers are working from the same version. A new version of the beta will come out usually a day or so before the old one expires, so there shouldn’t be any gaps between versions (and there haven’t been so far). So introducing a licensing mechanic into the beta wouldn’t solve the issue that you are referencing. We have been testing and working on our Update feature, but again since these are betas we can’t guarantee that we’d be able to automatically update each beta release to the newest version. So for now we will continue to release a new downloadable version of the latest beta as soon as it becomes available, which should continue to be prior to the end date of the prior version.
I hope you can be understanding of our reasoning, and you are of course welcome to test for us as much or as little as you’d like. Anything you are able to do for us (even just checking the tutorial every once in a while) is helpful and appreciated!
Yes I completely understand, I wasn’t sure how difficult it would be to achieve what I was hoping for, but I think I will follow your suggestion and not use it for a current project, as I would hate to lose my work so far – or even not losing it, but having to do a lot of work to get it back into a different version to keep working safely … it’s a shame, but I understand … I just wish I could do more testing, because I do enjoy looking for and spotting faults, but I’m just struggling to wrap my brain around what I am writing without making it even more difficult for myself.
I guess if I get bored, or just need time to think about things, I might come back to the beta and play around with it again.
FURTHER SUGGESTION: perhaps what you could do is modify the tutorial to include very specific tasks that allow you to get people to test the stuff you most want tested?
Testing the stuff we most want tested is my job – beta testing is for having you guys break the program in ways we haven’t even thought of yet But I understand your desire to help where it is most useful. Perhaps you could work on your project in the old version, and then help us test out the new beta’s import and export functions when you need a break. That way you won’t need to change your text around and you’ll still be testing with a more robust project than the Tutorial we’re all using. Just make sure to keep a clean copy of your project!
Sure – I certainly want to check out the new formatting and compiling, because the old version does some weird stuff and has limitations – eg: the way it replaces the “list-style quote” style in the editor, with an underlined style when it is compiled, and there doesn’t seem to be a way in the old version to stop it doing this, even though the underlining is not selected anywhere that I can see.
What I am writing is a series of 4 books in the one scrivener project, where each book has parts and chapters, plus a folder each called front and back matter ( divided into books 1, 2, 3, 4 ), plus a folder of writing “snippets” to be allocated to folders for each book, then actually placed and edited into the draft for each book … so as I get further into it, there will be plenty to test out on the importing and exporting.
Are those import export functions ready to test yet? or still being worked on?
But I understand your desire to help where it is most useful. Perhaps you could work on your project in the old version, and then help us test out the new beta’s import and export functions when you need a break. That way you won’t need to change your text around and you’ll still be testing with a more robust project than the Tutorial we’re all using. Just make sure to keep a clean copy of your project!