Me, too.
I would love for Geoff to start planning release more like a tik/tok thing, where you get new big features every second one and then put a bug fix thing between those.
1 Like
I would gladly trade a couple of feature releases for a monthly bugfix point/dot release. Even if it was just a few bugs. Keep resolving known issues and look like you ARE improving the product.
The current (slow) feature/fix release would not be as annoying. Like when a release finally comes out, a week after my license expires.
I suppose that might be preferable to the increasingly slowly released bing bang releases
Maybe still do features periodically (like now) and a monthly bug fix that is then rolled up into the feature release as well
changing something has to be better than doing the same old same old which seems to have driven people crazy since the day it was started
That’s what I’m asking for. I think they could do fixes biweekly, but update fatigue is a thing too. More frequent builds with fewer changes would be easier to test too.
1 Like
Wait, you have favorite bugs?
2 Likes
so, bug fix, fix API2 and events, rewrite web2, allow web1 back as it works(however chatty), remove android from the roadmap, get everything back to 19r11 so they can start all over again.
those sort of bug fixes, or just more random plasters over what is there now that is seemingly entirely unsuitable for a large part of the professional ex-user base.
I want to be so positive, but the cancer of the post 19r11 release has now infected the product and it will never recover, but thank goodness that’s just my opinion, or is it…
and again, i add, with the most respect to Christian who makes a living in this environment.
I cant use xojo for commercial stuff now as the initial test of ‘who the feck are they’ fails.
1 Like
Well, that is what I think. Many said that, even in the betas when that could be avoided BUT they know better 
There could be an exception with Android. I know that Xojo can´t keep up with the OS and the fact that the tool will be a half baked limited toy that I will not use and will attrac only a few naive new users. But, for some CURRENT users that need simple companion apps, could have its niche after those MANY years of development.
But once Android is in place, couldn’t some clever plugin 3rd party like MBS step in and fill in the gaps?
If it is half baked the Plugin will not fill any Gap. It will provide Spare functionality for a poor programming language, a poor IDE and a poor Situation. There is no excuse that for everything you need a Plugin and that many things you can not develop even only as a Plugin. Nice that there are Plugins. But when simple things need Plugins there is not a Gap: it is a lost situation. Knowing in front that Android will not work proper is a bad thing at all
Sure, plugins will increase the functionallity a lot. but it will be still limited and it is a extra license that in mobile, it must be keept upt to date more than on desktop.
I can’t understand why Xojo has the stupid necesity of reinventing the wheel and make it square.
For example, in B4X if there is something that is not included, you just use the NativeObject Class to access almost every native Java class.
Need something a little more complex? No problem, just copy and paste some Java code inline with the B4X Code.
You found some new component on GitHub, just write a wrapper and use it in B4X.
But with Xojo, they are not even using Java, they had the idea of using Kotlin, even if it has few Developers, Lack of Community Support, and very few repositories on GitHub.
Well, I guess it doesn’t matter if there is no existing code, you are not going to be able to use it easily. Plugins will be cumbersome and limited for experienced Kotlin users
You do realize that the only “big” plugin developer that hasn’t joined the MVP is the only one that is vocal about the user experience and it also happens to be the only one who does not seem to be in the mainstream as far as immediate plugins for holes that are just coming out in impending releases. In other words, the one non-MVP plugin developer is clearly on the outside looking in; where the other two are clearly insiders. It is a shame really, but if I am choosing who to support einhugur is the only choice of the big three.
I find that Einhugur covers most of my main needs well enough, and at a very reasonable price.
On the subject of MVPs which are supposed to represent user interests, I think plugin developers have an obvious potential conflict of interest, and so should be excluded from being MVPs.
- Karen
1 Like
In a way it makes me regret having suggested they add a plugin dev as an MVP
BUT since all they had was folks who didnt write plugins and that perspective IS important to be heard in whatever feedback they get about product developments
Is there a conflict of interest ? Sure.
But I had hoped they could / would separate their interests better
wouldn’t be so much of a conflict if the MVP were ambassaors, and not “police”
Not all MVPs have moderator status.
1 Like
but behaving like it. All of them have their own interests in that forum. Disturbing people speaking about errors, Bugs, Failures, idiotisms and so on have to be away. And if they can not get them silent they need to ban. Everabody in the meantime knows that I was right with Web 1.0. But the Cool Aid Drinkers had to complain that I complained while it was a not that bad product. Sorry: Maybe I am wrong in my wise of doing but NONE of my INFORMATIONS was wrong. That should be the painful part. But it isn’t. And all the MVP don’t wanted that
I think it ultimately boils down to two things: team size and QA. Xojo does not have a big enough QA team to effectively do any QA testing. That’s pretty much the only reason for the prerelease channel - get users to test as much of the product as we can before release. It’s somewhat effective but in my opinion ‘test everything’ pretty much means ‘test nothing’. At least there are some focus areas now in prerelease notes - but still not narrow enough (again, IMO).
The company I’m with has 6 dedicated QA people that do full regression testing on all major releases. To put that in perspective we have roughly 20 full time developers (not all are Xojo) that are split among 4 teams and effective we have a QA person on each team that handles the weekly testing and also participate in the regression testing near release time.
Small development team with even smaller QA team makes for a very challenging situation. With even more targets than ever the QA team should be growing with as much automated testing as possible for framework issues. UI always needs a human to look but with all the possibilities between the supported Mac, Windows, and Linux operating systems, the various hardware for Raspberry Pi and iOS and soon to add Android it’s an impossible situation for a one or two person QA team to keep up.
why then not do incubator release until its ready after a year and then release and not half baken deprecating
It’s not really them making a while a square, it’s really that they keep reinventing the wheel. Period.
Why create your own DB server when there are really good choices out there already? Why create your own bug reporting tool when there are really good (some even free) choices out there? Why invented your own accounting system when there are good choices out there? Just because they’re a software development tool company means they must write their own ancillary tools. If anything it takes valuable development time from the software that makes them money.
The Not Invented Here Syndrome means that they think they can do it better than anyone else in the community. With such a small development team they should be looking around and asking what can they leverage that’s already been done.
They obviously have done with that with LLVM. I’m not super familiar with Web 2 but it looks like they’ve leveraged a number of standard libraries (I guess we could argue if they’re using the best libraries but that’s a different argument).
I think they’d be better served by using more wheels that have already been invented.
I think you are being really unfair to Christian here. You seem to be implying that he has inside information so that he can plug gaps with his plugins. This is something that he has been doing for a long time so this inside information you speak of must have predated him becoming an MVP by several years.