This is entirely automated
Its how thy can chunk out so many builds in a beta cycle
Some people asked for bug fix release. I think Xojo Inc. listened and they increase the quality with more attention to bug fixes. As Paul wrote in the xDev Magazine, the next release 2021r2 will be mostly bug fixes beside a few smaller enhancement.
But the extra bug fixes may delay the release, so 3 month from 2021r1 does not work. And if the pace continues, we may see 3 and not 4 releases this year.
Since we got more bug fixes, some features in development are delayed and will be moved to r3 or the release after that. Please don’t complain that the feature you may have waited for is delayed.
1 Like
I think that misses the point… From what I have heard from multiple engineers a good percentage of bug fixes happen because they are in that part of the code for other reasons so some happen all the time even if not focusing on bugs… but then they can often languish for months before they find their way into a release.
If they put the fix first into the bug fix branch and then bring the fix into the new feature branch regularly scheduled bug fix only releases could happen without slowing other things significantly most of the time it seems to me.
Most bug fixes for a monthly bug fix release don’t need to be big fixes that take a lot time to do, but at least one that takes a lot of work should be scheduled every 6 months.
Yes the monthly bug fix releases would not (and should not) receive the amount of hype/press of feature releases, but just the fact that they happen would help inspire more confidence in the product, and the cumulative effect would be significant in customer perception of the company and the product IMO.
It would require a change in company culture… but I think overall it would be a positive for Xojo Inc.
BTW I think it is interesting to hear the change in point of view of former Xojo engineers after several years just being a customer again.
-Karen
1 Like
Not sure how to interpret this Christian. Either you trying to just tote the company line or just being this gullible. Do you honestly think significant increase in heated debates, escalation of heavy handed tactics, the creation of Pacifiers/MVPs (anyone that has read HungerGames can relate to the exact meaning), in the last three years culminating with just constant and blatant deletion of posts, removal of team members of which some have been public “evangelists” of the tool just a year or two removed; do you think there is ZERO correlation between those things? I can honestly say that this is the only forum and toolset where I have been privy of such behavior. I will admit that perhaps I am not an avid of a great many deal of other toolsets; but I do use some other ones (some niche, some not) and the amount of animosity generated by the tool owner in this case is orders of magnitude from any other. I appreciate the engagement, but to me the delivery does come through as somewhat empty. And before you remind me of “not shooting the messenger”, do remember that you chose to be the messenger.
4 Likes
disillusionment is what I call it
1 Like
You are right in that rapid releases are not the problem per se - I should have been more precise. After all, the old model of 1 feature release followed by 5 bug fix releases could be considered a rapid release model. The problem is rapid feature releases which lead to continuous and increasing instability.
Monthly bug fix releases would be VERY welcome.
Yes. I mentioned in the blog post that my time inside the company didn’t let me see what was going on. These are not new problems, but when you’re working with the code every day, the time between releases flies by. It amounts to blinders to the fact that the time between fixes is very long. It’s not intentional, and it’s not malicious. Plus old habits die hard and the Rapid Release Model - which I believe has fewer annual releases than the old model, but finding detailed history is hard - has been in place for a very long time.
All I’m asking of Xojo is to take a serious look at their process. There are ways to make more frequent fixes happen. I don’t know if they will do it, but I believe it would help.
2 Likes
From REAL Software Announces Rapid Release Plans for REALbasic - MacTech.com
2 take aways
- Works well for software as a service (salesforce etc)
- new technologies to our customers faster
Not sure more frequent releases is, by itself, any panacea
That was the premise of the rapid release model vs the old one
More frequent bug fix only releases might be one aspect of improving overall “quality”
Thats the lament that so many seem to have
Bugs sit unfixed for a long time (again not new)
1 Like
No. That’s why I write about needing more bug fix releases, and maybe fewer feature releases. I think this point often gets lost though.
bug fix only releases would be a wonderful thing
it would let them generate more consistent press or at least a steady stream of “hey we fixed …” kinds of press releases
that cant be a bad thing
The 9th item in Feedback is the request to make a “bug fixes” release.
I think that wish is getting implemented with 2021r2.
So I hope with a bigger emphasis on fixing bugs, Xojo can catch up and improve quality over time. It’s a process and it takes time.
That may not include your favorite bug or delay a new feature, but I think a few good bug fixes may be included for the 2021r2 update.
Let it not be a ‘one-time’ thing (this should be a continuous process, preferable with dot releases) and FFS, I hope they finally start testing it on real Windows/Linux machines before releasing as it is all to common with Xojo something is released and immediately a pile of new bugs come up that could’ve been avoided by doing some basic QA
1 Like
They should change away from rapid Release and they should modularize their IDE so they can update for example Web or Android or Ios only. One small thing to realize but a big step for the users and the company.
Releasing Alpha Status Software where many language changes coming up within the first three, four months while the development was mislead by Ideas which are not accepted by the users or while they are not working is then a risk when you automatically deprecate former versions of Language and IDE.
So a new Release Model is the most important step. Having and incubating Beta Release while the former one is in maintenance would get to clear results for the entire customers. There would not be any problem and not any aggressive behavior. Why? Because there is no deprecation from now to tomorrow where you don’t know how to holt your product on the market when developing under authority.
Combining that with Patches and Bugfix-Releases would help to make Xojo strong on the market. Java is exactly doing that. Java 17 is the next LTS Version of Java. Incubating since two years. But the 11 is under maintenance until 2029 from now on.
So the Gap between not supported anymore to under development is closed. That’s why reliability comes also with the Release System.
So Users which want to step in the known risk that there can be massive changes can work with the incubating version of it. Others can work with the stable branch without any problem. The Company would see over the time which features to implement and what is missed. And if one branch is totally lost: where is the problem?
Exactly. But it’ll be: “See we listened. Here’s a bug fix release.”
Then back to ‘normal’ with the lack of quality. Thing is the bug fix only releases are being begged for due to the lack of quality.
And in order to make a “Bug Fix Release Model” help to heal the division in clients… I think the following also needs to happen.
Publish a list of the specific “bugs” that are being targeted for the next point release… This will let the community know the 1) Xojo is listening 2) Xojo is doing something. All this of course with the proviso that while certain items were TARGETED, circumstances may dictate that they didn’t get completed, and that they remain targeted for the next release.
But even if this is done, significant “forward motion” must be demonstrated, otherwise it would all be another excerise in futility
The point is that there is no other Chance for the inc. They need to release and they need functionality and on the other side they need to fix the bugs. Without a change in the release policy there is no chance.Only with an incubating Release cycling there can be another chance while you then have two development branches: an incubating one with new features and functionality and a stable branch with the bug fixings for the Software. That stops deprecating of Software which is stable and protects customers from Beta State Software. Within that knowledge I have a message: they are not interested in this. I was asking more than once about it for another release cycle. But one of the major problems is the marketing. A feature you have in your incubating releases you have not in your major releases. That IS a major incident and stops chances to prevent but helps to sell Software with new Features. So what ever you think, suggest, believe or do: in case of Xojo your major problem is the need that a company like them needs money. And to earn that money you need every month you need to decide what your business is on the inside. If it is relying on ten thousands of users which all are renewing you have a comfortable situation. If not you need to generate purchases. And trust me it is hard to find 1000 people giving to you 1500 Euro to have 1.5 millions. Xojo has that kind of problems and they decided what is their way and that makes it uncomfortable for some users. Get used to it while it will not change.
1 Like
These are solvable problems. Xojo could drop the Year.Release numbering and do what Chrome/Firefox do and just increment a number. I don’t know where they would start, so for the sake of argument, let’s say they start with 10. So we get Xojo 10, a few bug fix releases, then Xojo 11. They could still do 2-3 per year. This rapid incrementing of version numbers is becoming more common.
This would also allow a change in release model, though I’m just spitballing here. They could sell based on the number of releases. So you buy at 10 and get guaranteed access to 10, 11, 12, and 13, plus their point releases. You’d have to renew/buy again at 14. This means customers know they will get a certain number of releases. On the other hand, it incentivizes bumping the version up more frequently. Quite frankly, assuming we’d be getting actual features in each, I’d have no problem with that. Budgeting would be hard on this model though.
But my point is there are options. This is just what I’ve come up with in a few minutes of writing. If Xojo wants to solve these problems, they can.
—
Here’s an example of the problem with waiting 3-6 months for a bug fix. I noticed that using For Each with RowSet seems to be triggering one iteration of the loop even if there are no results returned. So I just threw a check for RowCount around the loop and called it a day. I did not bother to track down the bug or produce a sample case or report it because I know 2021r2 is right around the corner, so at the absolute minimum, I have to wait for that to release and the next one. Considering the next one may be around December, it just isn’t worth my time. I’ll have to deal with this for at least the next six months regardless. So I’m not interested in going through all the hoops.
If I had any expectation of a timely fix, I’d probably spend the effort.
I would be very happy with 2 new features releases per year. And bug fixes and enhancements every 30/60 days. At some given point, 1 to 3 of those per year would be elected as stable and archived, the rest can be discarded after 3 years.
4 Likes
I’d love to be surprised and see them do this on a regular basis
I’m not holding my breath
This could incentivize the wrong behaviour - ie/ lots of releases with a tiny number of bugs fixed
If Xojo wants to solve these problems
Thats the crux
They have to believe they have a problem
I’m not sure they do
And then they have to want to do something to alter the current situation
I’m not sure they do
Unfortunately this sentiment has become far too common
1 Like