Plugins - Release Cycle

While answering another thread - a thought struck me.

Native Plugin fixes seem to fall within normal release cycles - is there any reason for that. E.g. There seems to be a few database plugin feedback requests marked as fixed but not released, why do they have to wait for the next major release.

If plugins have fixes can’t we just get them released? Surely any beta cycle for a plugin would be a lot shorter and a lot more focussed and get fixes into people hands a lot faster.

Just a thought…

+1

More alpha & beta cycles overlapping
And if the plugin beta doesn’t match up with the release do we hold the release ?
Or the plugin ?

managing them separately makes life more difficult

thats just my opinion - not Xojo’s position on this

Big deal…

[quote=100015:@Norman Palardy]And if the plugin beta doesn’t match up with the release do we hold the release ?
Or the plugin ?[/quote]
Course not, you release the current production plugin.

So, it’s difficult, but maybe it gets fixes/features out there in a much better timeframe and that’s got to be a good thing :slight_smile:

Maybe I’m wrong, but the more I think about it, why can’t the plugins not be treated as separate entities? Can you guys not release a new version of a plugin separate to a main release and vice versa? Seems to me that there are fixes in the db plugins ready to go but they are being held for a major release - why…

There may be excellent reasons why this can’t be done but I can’t see them.

[quote=100029:@Patrick Delaney]Big deal…

So, it’s difficult, but maybe it gets fixes/features out there in a much better timeframe and that’s got to be a good thing :slight_smile:

Maybe I’m wrong, but the more I think about it, why can’t the plugins not be treated as separate entities? Can you guys not release a new version of a plugin separate to a main release and vice versa? Seems to me that there are fixes in the db plugins ready to go but they are being held for a major release - why…

There may be excellent reasons why this can’t be done but I can’t see them.[/quote]
We already have an enormous work load, an alpha & 2 betas going on and you want more ?
Stretching engineering staff further to run more betas at the same time doesn’t make things “better” just “busier”
I think you’d get push back from engineering staff that are already working very long days 6 or 7 days a week

And that plugin that you want Right Now… Still needs beta testing. One of the issues we struggle with is that when multiple alpha or betas are going on, there’s less focus on each of them individually. In my opinion adding more simultaneous betas just spreads our testers even thinner. Better to have more eyes using the new plugins as part of a regular beta.

Fwiw, there are times that plugins require something that ships with a new IDE, so it may not be practical anyway.

Employees that have 6 to 7 very long working days a week could burn out. It is a bad award for the employer. If it is the normal work pensum for your employees, Xojo Inc should support less platforms or increase their development staff.

Course it needs beta testing, not suggesting otherwise. Personally, I would have thought any beta testing cycle based purely on a plugin would be a lot shorter and a lot more focussed. Wonder how many eyes really focus on any plugin fix as part of a regular beta? The regular betas are so vast (100’s of fixes/changes) that, personally, I simply don’t have time to go really in depth to all of them, all I can do is put my own projects through them - if they work - fine. Don’t get me wrong - it’s great you can get so many fixes out there on a main release!!

What I was getting at was - can the plugins be taken out of main releases so fixes get out there quicker - is there an opportunity? I’ve just had a thought asked the question - that’s all.

TBH, the answers - we work long/hard enough already and it’s difficult to manage didn’t really answer whether it could be done! Those answers raise other questions that I’ve taken offline.

That’s an interesting statement, I was under the impression that plugins are completely isolated from the IDE. I thought a plugin was completely encapsulated and therefore independent of the IDE. Obviously, you guys know what happens under the hood so I’m wrong! This is the only reply that’s given me an answer I can understand.

Anyhow, thread has run it’s course as far as I’m concerned!

Less is more in many cases, but this is one those cases where LESS never will be. :slight_smile:

  1. The good way should be adding more people to work dedicate to those parts (if financially able to) and they taking care of separate dev cycles, plugin installers and updaters, beta testings, etc.

  2. The “alternative” way (seems the way to go here) is finishing a release and starting a dot release just after to stabilize the known minor problems and including extra features like updated postponed plugins.

  3. The worst way is not doing 1 or 2.

They’re separate from the IDE, but plugin updates may require changes to the framework. For example, new SDK functions or bug fixes.

Fair enough - makes sense.

Hello Rick,

I really believe the main way for Xojo is to support less platforms or increase their development power. Xojo is lagging behind in current Windows OS development, the Mac OS development, on Linux are enough problems. In the near feature we have with iOS the next supported platform. With the same development power, there is than less time for all supported systems (iOS, Mac, Windows, Linix, Web).

On the other side the speed in development of iOS, Mac OS, Windows, Linux and Web seem to increase with more radical changes.

Im curious about the steps Xojo Inc chooses to stay up-to-date.

They added staff to do Web, then they added staff to do IOS, so your conclusions are not completely accurate.

Thanks, that is good to know.

With my view from the outside (and lots of read post in this forum) I got the feeling, that they are lagging behind the state of the art on many platforms and started new ones. I would like to see, that the lagging behind on the supported platforms gets more irrelevant before starting new platforms.

Just my 2 cents

[quote=100432:@Torsten Gaidies]Hello Rick,

I really believe the main way for Xojo is to support less platforms[/quote]

Can you imagine the damage this would cause for the product? :slight_smile:

“Hello guys, I’m sorry if you use Windows, we decided to stop supporting this platform because we believe, since today, that dismissing it should be beneficial for us. Thank you” :stuck_out_tongue:

When they decide to support some platform they must be sure to follow this path until the end of that platform, or the expected lifetime of their product. If you abandon your user base, your user base abandon you.

Yep,

it is not an easy decision and shouldn’t be the first one. The supported platforms should be nearly up-to-date and then I would see the possibillity to add new ones.

But they have the inside view, that I’m missing. So I hope they have choosen the right way to suceess for all of us. My gut instinct says: “I’m not sure on that point”. On the other side Tim wrote, that Xojo added staff, which is a positive signal.

I though Joe Strout was back as a contractor not regular staff just to get iOS off the ground.

I was sorry to see him leave RS. If he is really back then great (though unfortunately he does not post at all … He was such a major helpful presence on the NUG back when I was starting out with RB!)

  • Karen

Whether he is contract or not, I don’t know. The point is they brought in more bodies. They didn’t pull an engineer off Windows, for example, to do iOS.

FYI, on each branch, when we release an Alpha, a Beta or a FC, we build & release ALL the Database Plugins in the same step. We do it each time we release a Xojo build cause it’s part of our Build Process. If you think you didn’t get a fix in a plugin build that should be in, please drop me an email with the case #. Finally, don’t expect to see any fix in a build for which the case status is not “Fixed & Verified”. This is pretty possible that a “Fixed” case belongs in a build, but that’s not a guarantee. “Fixed & Verified” is.

I don’t know how else to say this - this was never a comment on the current processes - your current process builds/releases all the plugins, I get that.

Bit extreme an example but a bug fix in a plugin 3 days after a main release has to wait till the next major release which can be a quarter away. If a plugin is simply dropping the .xojo_plugin file into a plugins folder and no IDE/framework update is also required, why does someone waiting on a fix have to wait that long? My question was merely wondering if the plugins could come out of your main process and go through it’s own quicker beta/release cycle and therefore get fixes out there quicker. I was just expressing a thought, not criticising engineers or the current process which I suspect some are interpreting this as!

Now Greg/Joe tells me it’s not that simple as sometimes plugin releases are reliant on the major release - fine. Not always the case though :wink:

(I know I said this thread was done! :frowning: )