Xojo’s ?
I dont think there’s any technical impediment to them having an LTS version
They use svn and have a small team so multiple branches shouldnt be an issue
As greg has noted several times over the years their build infrastructure can build things automatically and I expect that it should be able to build whatever
Not sure there’s the will to do it though
Again in part because it is a pretty small team
But at this point what we’re debating is an unknown program with unknown features with unknown releases
We just have to wait and see how this is going to work
1 Like
I’ve read some lines from Greg that supports an idea of Xojo not having any intention of having a double support of releases (current+LTS)
So it’s easier to assume that a model like Continuous Delivery, marking the STABLE ones, is a more feasible one for Xojo.
I would tend to believe this is the path they will follow
Again, not that they MUST, just that they WILL
I dont think there is any technical impediment to an LTS version
The will, time, $, and other things probably dictate that more than anything
I think the only prerequisite is that you have an active Xojo license. That seems fair - there are many aspects you couldn’t test if you had an inactive license (or had never owned a license) such as building.
Today, yes, but you only get into the process at the final stages, after alphas e some betas. In the near past Xojo Pro only had access to beta and beyond.
Do you mean an “alpha group” ?
That was always by invitation only
I dont think its used any more though
Couldnt tell you when it fell into disuse
But you didnt have to be a Pro user to get into the beta’s
https://forum.xojo.com/conversation/post/311507
If you HAD a Pro or Enterprise, now Pro+, license you were automatically part of the beta
A lot of Pro and Enterprise users I dont think knew that or took advantage of it
Now I think the “alpha testers” are the MVP’s
I feel that the “open club” does not have access to the first beta as before. Sometimes I see it like beta 3+ or something. From some point where things are more or less frozen and debated only with some close pals.
When I was there this definitely was not the case.
Betas were betas and anyone in the pre-release group had access to them.
As far as I cen tell from what little we’ve been told the MVP’s are testing the builds. They’ve said so on a few occasions. I suppose that could be “alpha testing”
After that I would guess you’d call them “betas” but Xojo isnt putting that label on them. They’ll just be “builds” and at some point they’ll just say “this is a good one thats the release” or something.
None of us know at this time how this is going to work.
seems the “goodbye beta hello build” post has been updated 
to remove the detail about installers 
we’ll just get builds with installers once they are feature complete - which is still a tip that they believe they have moved from “beta” where features could disappear/change (could they ?) to “almost ready to release” or something
Certainly seems like it will just perpetuate the feeling of “permanently in beta”
IMO It always kinda of felt that way anyway.
-Karen
1 Like
Reading my previous message and I feel… I miswrote a bit what I was thinking.
I do not really care (far more since the r2 / API2 initial debacle) about (beta) testings.
What I wanted to say is that a testing group have to have time and knowledge to be inside that kind of group.
Everyone can undertand that at each release. New releases are built on Thursday of Friday and available for download on Tuesday (and that is good). A recent one was postponned for some days because of a last minute discovered bug… Fortunately for the licensed people.
What must to be done for testing a new version (before and after its release) ?
Create a new project and populate it with many builds, generate the applications, and if possibe, doing that for all supported platforms.
But, if you are a Pro - make living with your application(s) - you cannot take time to do that, IMHO. Or you can take time on Saturday or Sunday and do that on “free” time. Even with good will, this is frakly different ta-han making real debugin’…
“Only time will tell”, and I hope not past.
Most definitely.
Not so much specific knowledge - a lot of people just test with their actual working projects esp when they are large projects. As you note not everyone can take the time to create a new project and test whatever aspects they reported that are now fixed. If you are earning a living writing code then thats can be a hit.
By the time things get to public releases for testing they NEED to be feature complete.
Otherwise if you try to use something and then that feature is pulled you’re in a bad spot.
And that is, in my opinion, where this process falls apart.
No one wants to test a new version that isn’t feature complete and use it when whatever new feature could still be pulled out. Its too risky
And I believe that contributed to why people waited until FC to test. They knew that by that time nothing would go missing. So it was “safe” to use that version as is.
And thats NOT on testers. It’s on Xojo about how they manage(d) the beta process. It wasn’t uncommon to get to “beta” and NOT be feature complete. They probably should have delayed the beta. Instead they continue to ship betas and, like in the 2019r2 cycle, a MAJOR change took place during the beta cycle (the event renames) and anyone using the beta to do work was now in a very bad spot. They had to either continue and live with those changes which eventually got pulled out causing them to redo work at least twice. Or go backwards to an older version and lose whatever work they had done.
And it still will be on Xojo to manage this process.
But since no one will necessarily clearly know when things ARE feature complete and “safe” to test they may just wait longer.
Or I could be wrong
We’ll see wont we ?
1 Like
Nobody, nobody, nobody should be using a beta for main development.
And therein lies the problem
The people that Xojo does want to beta test do not have time to beta test extensively
I have used betas and made changes to my code base (which is of course all in SVN so its easy to revert) simply to make sure that the bugs I have reported that affect me are indeed fixed
Some times you have a hard time determining that from a small sample project
So people do test using their big projects
And its definitely risky
Not because its a beta but because the beta may not be feature complete &/or a feature gets withdrawn. And then you have to revert (you do use git or svn or something right ?)
Which I’ll repeat is not a good idea and not the purpose of a beta build.
I’m a heavy Mac user, my first Mac was a black and white machine, I’ve always beta test for them and every single beta has come with the same warning about not using it for production use on your main machine, it’s asking for trouble.
Which is why you use a version control system and can revert IF things go funky
Or a branch of your main code
There are lots of ways to use your main code base and be fairly safe.
BUT having to revert means any other work you might have done is also lost.
And thats a waste of time for that tester.
People want to see that their bugs are fixed.
Some only show up in large projects. If Xojo expects people to be able to test, at scale, in large projects, then people will do something like this. They have no choice.
Who is going to create a giant sample program just to test ?
No one.
And so people have waited and waited until they knew things were feature complete to test.
Historically the only way to know was to wait until FC as Xojo never said “ok this beta is now feature complete” or gave any other indication.
And now we will have less indication of that point when really all thats being hunted for is bugs.
Beta testing is, was, supposed to be about “field testing” and finding those remaining glitches not for hashing out new features. Thats more like “alpha testing”
EDIT :
FWIW I dont disagree that “betas” shouldnt be used this way
The reality is that it happens and ignoring that reality is what lands us with processes that are the way they are
I came to that conclusion while working for Xojo and worked VERY hard to make it so any code that was going in a release was just needing extra debugging when we hit beta and not a feature that was going to be introduced DURING beta. I’m sure the guys that are there still try and have mixed success as well.
It’s the difference between the sensible person downloading a beta and loading there app into it to test it vs the moron who uses the beta and sees it as the next upgrade to their current one.
It’s like people who download iOS and macOS betas to their daily driver phones and Macs. Then when something goes wrong they bleat about “crappy Apple”
I think we’re saying many of the same things but talking right past each other
Anyone who sees a beta as the next great upgrade should not be doing beta testing
I throw anything I do in a beta out because I can - I have everything in SVN or Git
But, the reality is that Xojo has LOTS of beta testers who DO use it as an “early sneak peek” and do treat it like the “next great upgrade”. And, after a decade in Xojo, its not something that has EVER changed regardless of how many times it was said “Do not use betas like this”
I dont see this process changing that behaviour from users.
So why not deal with reality and make sure that when you do start beta you ARE feature complete and code is relatively stable.
2019r2 and the introduction of the event renames at beta 15 is a perfect example of how NOT to run a beta. That was a huge change and betas went for another few months dealing with everything in that change that was not fully baked. That change should have been held for a new version later not shoved in to an already running beta cycle.
Changing whether you name something “beta” is only a cosmetic change.
It needs to be a full process change driven by Xojo since they control the entire thing.
The code needs to be “stable” - bugs or limits may still exist and thats what the testing will reveal. But we shouldn’t be introducing big new features. Builds need to be a slow progression of fixes from one with bugs to one with fewer and fewer and those new features go in the next cycle.
I dont know if that management of the process will change by changing the name from Beta to Build
We’ll see
Yes, but my reply was specifically to your line :-
MY point was…they shouldn’t.