I've created a new wiki page about beta testing. Feel free to edit it to improve it, or link to it from other pages.
Nice. I've linked to it from http://wiki.logos.com/Update_Channels and added some links to the upper-right.
Nice job, Mark. Very clear--with one exception (for me): First, it has been a while since I heard about "stable channel." I had only been thinking of "beta" and "default." While I understand your explanation about "setting to stable" in the middle of a beta cycle--and not being able to "go back" to an earlier stable version, I am still not sure what you mean by "default" will go back to "whatever default is: stable or beta."
What adds to my confusion is the memory of a Logos employee (don't remember the thread) that recommended we set our channel to "default" if we didn't want to automatically start downloading the new beta. My channel was ON "beta", and when we went gold for 4.0b (for instance), I switched to "set channel to default" which kept me on that stable release, rather then going on to further betas. So to me, it sounds like how you describe "default channel" is different than what I have understood "default" to be, and actually, my understanding of "default" seems a bit more like what you are describing as "stable."
Am I misunderstanding something? (wouldn't be the first time!)
Thanks anyway for a great overall page.
Dan,
Let's assume that the program's update channel is set to default.
If you have a Beta installation it will update to Beta 1,2,3 etc. When it updates to RC1 then the program no longer considers itself to be a "Beta" and will only look at the stable channel for an update. This means that it would skip any subsequent Release Candidates until the final one was pronounced "Gold" and published on the Stable channel.
Using Set to Beta locks it into that RSS feed which means that it will catch every Release Candidate but also it will not stop when the next cycle starts. Using this command over-rides the default behavior. Setting the Update Channel to Stable is functionally the same as the Default behavior for a Regular installation.
Kevin is absolutely right.
The confusion is understandable. It's because there are two channels (beta and stable), three states (beta, stable and default) and four versions (beta, release candidate, gold, and service release).
But I think of it this way. Release Candidates consider themselves to be stable, but all the other versions consider them to be Beta.
The confusion is understandable.
Thank you! I feel much better now.
I really liked the grid you posted in the other place. That is what enlightened me. I would be great to have it on the new wiki page. What came on which channel in the past is history. The other grid shows the future.
I could wish one did not need to know what he was running in order to determine what he will get in the future. It would be great if the action was consistent regardless of the current state. I wish the following was the case.
It would also be helpful if one could only set the option to a valid choice. Not like today when someone can say "obsessive compulsive." [:)] I what what releases obsessive compulsives get? [;)]
I just read the page, Mark. Thanks for all your work.
I have a question and it should probably be addressed to the developers, but it impacts this page too.
If I have two installations (one 'gold' and one beta) of L4 using the same Logos account (whether on two computers, or two user accounts on the same computer), syncing between the two versions becomes interesting. For example, when importing Libronix notes was being tested, those notes also copied to my non-beta system.
What happens with beta level resources (like the new version interlinears in 4.0c)? Or, if I have a new version interlinear open with specific settings, save a layout, and then open that layout in my non-beta system?
So far, I've not found this to be problematic, but it has potential. In other words, an added danger in the beta version is that even if you are running one stable release with a parallel beta release, the stable release has potential to be corrupted, or to have 'issues' when it syncs to your account.
Let me give a future example, since our past has not yet proved problematic. Let's say in 4.0d we start testing the Sermon File addin. Let's assume that doing that will require a modified dll in the Logos4 subsystem, so that the SermonFiles will behave more like regular resources, just like the PBB's are supposed to be. Now, let's also assume that I have some of my sermons on both computers. The beta gets an updated dll and file format for the sermon file. What happens to the sermon files on the other system. Since my sermon files are in the 'cloud' attached to my account, they will likely be downloaded to my stable system, which doesn't have the correct dll to read them, likely causing a crash.
Okay, that's all speculation requiring a number of things changing at the same time. Not likely for this case, perhaps, but a logical possibility, generating the question as to whether one's stable system is truly and completely safe, when I am running a beta with the same user name.
Anyway, I've been wondering about this for a while, maybe someone else has a better way of thinking about the potential issues here.
In other words, an added danger in the beta version is that even if you are running one stable release with a parallel beta release, the stable release has potential to be corrupted, or to have 'issues' when it syncs to your account.
Yes, I do agree with you, and the very last FAQ raises this problem. You might remember there was an issue of duplicate collections in the beta cycle of 4.0b, which caused data loss for some. Having said that, Logos doesn't sync new features back to old installs. Passage lists, for example don't get synced to 4.0b, but as soon as you upgrade to 4.0c, they'll get synced. It's pretty intelligent.
The only likely problem will occur when your data gets corrupted on your beta machine, and the server then syncs that corrupted data back to your non-beta machine. AFAIK, it's only happened the once, but if you value your notes, you need to make sure you have good backups.
Logos doesn't not sync new features back to old installs
My logician's mind is writhing in malformed truth tables ... do you want to put me a ease with a minor edit?[8-|]
I would be great to have it on the new wiki page.
There's some discussion in another thread about that table. I think Kevin's going to add it soon.
The following is currently the case (it's only slightly different from your desire):
Logos doesn't not sync new features back to old installs My logician's mind is writhing in malformed truth tables ... do you want to put me a ease with a minor edit?
My logician's mind is writhing in malformed truth tables ... do you want to put me a ease with a minor edit?
Logos: ~ (~sync) New Features -> Old Installs
Or (double negative), Logos does not disable synchronization of new features, with the result that non-beta installs will be safe from those new features.
Or (positively), Logos synchronizes new features, which are then available for syncing with non-beta installs - and this can't be disabled.
Anything for you [:D]
Default - you get Gold and SR's if you're running an RC, Gold, or SR; you get everything if you're running a beta
Good. The only logical rub for me is that "default", as it stands now, has two very different meanings. But changing that means that Logos would have to change things that are difficult and confuse folks who know the current method.
Thanks for all you work on this. I hope I did not steal too much time from your sermon preparation. [:D] The videos are good.
The only logical rub for me is that "default", as it stands now, has two very different meanings.
Sorta ... Default means that if you are running a beta it will act like a beta; if you are running a non-beta it will act like a non-beta.
This is great, Mark.
I'd like to see a section in there about one of the expectations of beta testers is that they will report bugs when they find them. And then provide a link to the page about how to report a bug, which in turn links to the pages on how to enable logging, and how to upload logs.
The Bug Report page should probably be beefed up a bit, too. There has been a lot of confusion about what is the best way to report a bug in order to get it noticed and addressed by Logos. I met Melissa Snyder earlier this week when I was visiting Logos in Bellingham. She says she only has time to keep up with the PC Beta forum, so that is the best place to put beta bug reports. And she skims the Logos 4 forum for posts with the prefix Bug: or Crash: So that's what we should continue recommending to non-beta users who have bugs to report in released versions. I found out that George is no longer working for Logos (he was an intern) so it's really just Melissa now responsible for keeping up with all our bug reports. I don't think she's been able to keep up with the wiki bug tracking system very well lately. They know they need to hire someone else to help her out, but there have been other higher priorities like hiring more developers.
I'd like to see a section in there about one of the expectations of beta testers is that they will report bugs when they find them.
We estimate from server logs (e.g., requests to the "beta" channel feed) that there are about 300 computers running the beta (or at least checking for updates, give or take, my numbers may be out of date), which is much higher than the number of active users in this forum. So we just assume that 90% of testers aren't encountering any bugs and the ones that are reported can't be very important. [:)]
I'd like to see a section in there about one of the expectations of beta testers is that they will report bugs when they find them. We estimate from server logs (e.g., requests to the "beta" channel feed) that there are about 300 computers running the beta (or at least checking for updates, give or take, my numbers may be out of date), which is much higher than the number of active users in this forum. So we just assume that 90% of testers aren't encountering any bugs and the ones that are reported can't be very important.
We estimate from server logs (e.g., requests to the "beta" channel feed) that there are about 300 computers running the beta (or at least checking for updates, give or take, my numbers may be out of date), which is much higher than the number of active users in this forum. So we just assume that 90% of testers aren't encountering any bugs and the ones that are reported can't be very important.
Naw, it just means that 90% of the beta users are sensible folks; they are aware that they have other lives and they don't have time to be the unpaid QA department for Logos... ;-)
there are about 300 computers running the beta
Welcome to the "300 Club" [:P]
Cheers
Can we get a pin to wear after we post 10 valid bugs?
Maybe with a bar under it, for 25. And a sparklie gemstone for 100?
The Logos developers job is to ensure its impossible for anyone to be able to earn the gemstone so Bob does not need to buy them in the first place.
[:)]
"unpaid"? You get paid in betas! And just look at what happens when that source of funding dries up... :-)
Sounds like a plan...
And here I was hoping that the top error finder for each beta would get 1 free resource - I have my eye on some pricey commentary series.[:D]
And here I was hoping that the top error finder for each beta would get 1 free resource
Maybe Bob has some unsold Coptic lexicons, or maybe a Unicycle thats spare.
( One of his older posts spoke of some important matters, but i mostly remember, with a smile, his Coptic Lexicon and Unicycle stories. Not sure why, but those stuck with me ... [:)] )
