I realize what your point was.
What people should do and what they actually do arent the same.
Thats all I’ve been saying.
I sure hope this change doesnt negatively impact participation in the betas
I could imagine how it might
Honestly? If people can get hold of a beta then they will get “Shiny New Syndrome” and install it as their daily driver. It’s human nature and I’ve seen it time and time again. The number of times I’ve seen clients using it and my server logs show a massive percentage of pre release software accessing. I wrote a blog post on this a couple of years back.
This is precisely my point. If we don’t want people using betas as their daily ones and rely solely on “Yeah dont do that” it wont happen. Ever.
But the industry sticks to that and then shouts “Oh but you should know better” or “Yeah we warned you” when someone does have an issue.
You know that. I know that. Xojo knows that. Everyone who writes software pretty much knows it and has experienced it.
So maybe what needs to change is not trying to convince the rest of the world of the error of their ways. It hasnt worked yet.
Maybe we need to change how we release software.
And set better expectations of what alpha and beta mean (and when we say they mean X stick to it. IMHO alpha is “features could change”, "beta is “we’re feature complete & JUST hunting bugs”
Make betas MUCH better. Make sure they ARE feature complete and “beta” is bug hunt time and not “Oh we might add significant new features” time. (Thats what Xojo did with 2019r2 and why that cycle was such a long mess)
Doing that would go a long way to getting more useful testing from users as they might not be scared as hell to touch it because “Well it IS a beta and might eat your dog, your machine, and your homework so be careful”
If folks knew it was EXPECTED to be quite stable and reliable and wouldn’t change significantly WHILE they are testing it they’d be more willing to invest their time.
Anyone that expects to significantly influence the direction & features of a product shouldn’t be trying to do that as part of a beta. Thats more “alpha” testing. Something Xojo abandoned years ago and seems to have restarted with the MVP group.
Alpha is: the thing is under heavy development, things can drastically change, can be very unstable, internal team only can test it. Beta is: The internal team thinks it is now feature complete, and working, and stable; their tests are ok. So a larger external team can test it deeper, a larger bug hunting starts, things can change, including features, but it is not expected to. When no more bugs are found, a Release Candidate 1 is queued, if something is found soon, it’s fixed and a RC2 comes in, and repeat the process until the last candidate is renamed as Release and is published.
Are you referring to how Xojo does it now or in general ?
I’ve worked at places where things were exactly alpha is “features could change”, "beta is “we’re feature complete & JUST hunting bugs”
Any “the thing is under heavy development” stage was before alpha started
There is no hard and fast rule, everyone does it differently. At the end of the day you can’t have any expectations of the quality of a pre-release product if you’re using it for mainstream work.
The books of the phases are a bit flexible, adapted per institution, but some formal phases can be seen bellow. There’s no frozen, untouchable rules, just a bit conservative in a Beta phase. Have in mind that Alpha is based on engineer’s point of view and in Beta they will get a wider “users’ view”. If the final users says you are totally wrong in some feature, it’s better to rethink in rebuilding the ENTIRE feature or you will just fail. You don’t write software for your engineers’ team, you write it for your users. So, there’s no such thing of “features can’t change” in beta.
Phases of an Agile Project:
Discovery, alpha, beta, live and retirement.
You’re right. There is no hard and fast rule
15+ years of the current process for betas & releases has had these issues from the very outset.
And there’s been very little done to deal with the reality
Usually its just the admonition “Dont use betas for real work”
All I’m suggesting is that after 15 years of this, and having the same problems year after year, release after release, maybe they should switch what they put out as “beta” and recognize that betas really need to be more like early FC’s where all thats going on is bug hunting
Big features dont get put in, or pulled out of “public betas”
Much like what you get from Apple Google MS etc
By the time they are putting out betas they’re in “bug hunt mode” not “feature addition/subtraction” mode
I dont know that this new process is going to do that
We’ll see
Agreed, my post was in reply to Rick’s description of betas.
I’m not sure what model Xojo tries to follow
I guess I just expect that BETA means “feature complete and we’re just hunting bugs”
Not what we have had in the last while (certainly not the 2019r2 cycle again)
Almost this. The truth is “engineers thinks it’s feature complete and functional, and we will hunt for bugs, but… sometimes… point out some necessary resources that they forgot” 
As long as they dont repeat the 2019r2 debacle where a HUGE change got dropped in beta 15
IF Xojo had cut right before that, called that R2 then worked on the event changes for “R3” it probably would have gone better but … 
I’d like to avoid a repeat of that
2019r2 was poorly engineered. The api2 transition was bad designed. The way of moving to api2 is not pleasant, the way of maintaining api1 legacy is impossible. Beta15 wasn’t enough. That thing deserved retreat to alpha for entire redesign.
1 Like
I would totally agree
That the output, 2019r2, was eventually removed from distribution was particularly telling about how that whole cycle went
I HOPE that this new process is JUST about trying to encourage people to not wait until FC.
However, its hard to not also remember that this new process is coming shortly after the whole API 2/2019r2 release cycle. It seems almost like it could be an effort to restrict unwelcome feedback. I dont know how else to say that.
But until builds land who knows ?
That we’re still debating this stuff and dont have any build to even start evaluating is an entirely different issue
I’m a strong critic but also a very supporter of Xojo. I don’t know what will come, but I still hope some new release after 2020r1 fix the hole they opened in the legacy code. They should have sub-folder inside the tool, like “legacy”, and all the tooling necessary to handle API1 ONLY mode legacy code, switchable by a preference in the IDE, there. It would enable old plugins and all, including the api1 help. Also, in mode api2, we should have 2 sub modes, pure and hybrid (that should be avoided, the current mixed autocomplete is a mess), in pure, things like DIM and whatever api1 code would give us a compiler error. I’m in hold waiting for an unknown future. Let’s see…
For what it’s worth, I always used to use the betas as my main daily driver. When the pre-release cycle started I would create a new branch in Git and then only use the betas on that branch. If Xojo f**ked something up royally I could always revert to my “pre-beta” branch. Sure I’d lose some work but in reality I never got bitten by that bug. I always thought that it was disingenuous to be in the pre-release program unless I was using the beta build all the time. Otherwise I’m just playing with a new toy and not moving the process forwards.
Where I think Xojo jumped the shark with 2019r2 was that they didn’t listen to any of the feedback they were getting about the API 2.0 event name changes. What’s the point of having beta testers if all you want to hear is “yes Geoff, everything is amazing Geoff, change nothing Geoff”. I’m hoping that’s not what the MVP program turns out to be.
1 Like
At this point not practical
Not that they coulndt have done something different and made something like this possible but they’re too far down the road with things as they are to reverse course and do something like this 
There’s a LOT of things that could have been done if they hadnt been in such a damned hurry to get it out the door but …
I see quite a few Web FC fixed today.
That there were / are that many still tells me we’re not that close to a beta build yet
maybe next year will be better… I am told 2021 is supposed to be different than 2020 