Suggestion: Plugin Version Testing

[ThePaladinTech]

Suggestion-

With each upgrade there has been snafus related to plugins, I don't see this changing. would it not be possible to do something like firefox does and 'verifies' the plugins work with the new version???

Everything about the Firefox Plugin / addon system i would think could be instituted within Sage?

Things like:
1. Check if the plugin works in new version and disable it if it does not.
2. if I plugin doesn't work in the current system do not show it in 'all plugins' - Honestly, why show it?
3. it might be nice to be able to ask sage to update all installed plugins? (not quite sure on this one)

It appears that already at least one plugin I use has been abandoned by its maker, if you don't implement some system to trim the dead wood from the 'all plugins' list it is going to become unwieldy! I understand Sage doesn't test all the plugins... I don't think this would be necessary to accomplish the goal. just have a 'supported versions' property in the plugin? if your sageTV version isn't in the 'supported versions' of the plugin the plugin will be disabled (if installed) -or- won't show up in the plugins (if not installed) ... I would think it must continue to show up in the 'installed plugins' so a user can both know the plugin is disabled, and remove it if they want.

Plugin Authors would have to test there plugins against the new version, and then update the 'supported versions' property... Some more work for the plugin authors. But aren't they doing that already retro-actively? Wouldn't it be better to just have 7.12 work when you upgrade then have to explain the steps you must take to make it work? And THEN have threads explaining how to fix it for people that didn't follow the upgrade steps? I mean wasn't the plugin system intended to make it easier? This would make it easier :)

[Fuzzy]

I think the best option would be to have a max version in the requirements. just as there is a min verions (most stv's in the repository are set with SageTV v7+). You could, i suppose set a min version of 7+, then a max version of say, 7.0.12. Then, however, your plugins will not function in the new versions until the author checks it and updates the manifest.

That said, i think the only major problems that have come from sage upgrades were the theming issues between 7.0.11 and 7.0.12, and that was due to a significant change in the say theming works. That is something that is likely to happen in the beta cycle, but NOT after release.

[GKusnick]

Plugin devs already have the ability to specify the MinVersion and MaxVersion of Sage they're compatible with. What you're suggesting, if I understand you right, is that plugin devs should always specify MaxVersion = current version. If they did that, all plugins would stop working every time a new Sage beta came out, and users would have to live without those add-ons while the plugins devs scramble to update them. And this would happen over and over again with each new beta build.

This would not, in my opinion, make anyone's life easier. The normal practice now is for plugin devs to leave MaxVersion unspecified, so that their plugins remain enabled when Sage is upgraded. There's a chance on any given upgrade that some plugins might break, but that still seems better than a guaranteed outage of all plugins every time, which is what you're asking for.

[gplasky]

This is a beta with rapidly changing items and updates. (Improved files to download and install from in the forums and beta public releases.) The rule of thumb is if you can't afford to have your version of Sage broken or to revert back to a previous version you shouldn't be installing the beta. Public release of betas are for testing purposes only. And feed back is both encouraged and welcome. There is also a learning curve for devs as they figure how it all works and to get past bugs in the beta core and apis. Once the version 7 of Sage is released THEN it would make sense in locking down the plugins and looking at using and specifyng the maxversion of Sage.

Gerry

[Fuzzy]

This is a beta with rapidly changing items and updates. (Improved files to download and install from in the forums and beta public releases.) The rule of thumb is if you can't afford to have your version of Sage broken or to revert back to a previous version you shouldn't be installing the beta. Public release of betas are for testing purposes only. And feed back is both encouraged and welcome. There is also a learning curve for devs as they figure how it all works and to get past bugs in the beta core and apis. Once the version 7 of Sage is released THEN it would make sense in locking down the plugins and looking at using and specifyng the maxversion of Sage.

Gerry

While I do agree with this, i think one major distinction here, is that while yes, this IS a public BETA, it is also a paid beta, so some level of reliable functionality would be expected. I'm not mentioning this specifically in regards to the maxversion thing, just that it isn't as easy to disclaim problems simply because it's a beta for testing only. If that were the case, they would have let it run in beta for free, and only charge for v7 on release.

[gplasky]

While I do agree with this, i think one major distinction here, is that while yes, this IS a public BETA, it is also a paid beta, so some level of reliable functionality would be expected. I'm not mentioning this specifically in regards to the maxversion thing, just that it isn't as easy to disclaim problems simply because it's a beta for testing only. If that were the case, they would have let it run in beta for free, and only charge for v7 on release.

Again, paid or not, beta is still beta and bugs and issue are a part of it. Given that, the core of Sage 7 is stable. But a beta reaches a point where it needs to go on more disparate systems to ensure stability. I think we have all become spoiled with the level of stabiltiy that Sage provides. I expect updates and changes to possibily break or cripple something. I would be fooling myself if I didn't. Sage is also quick to correct and work with the public beta users. You pays your money and you takes your chances. But make sure you go into this with your eyes wide open. WHen I paid for this beta I expected nothing different than what I had received from previous public betas. Same quality whether I paid for it or not.


this IS a public BETA, it is also a paid beta, so some level of reliable functionality would be expected.
I think the level of reliability has already been attained on this and previous betas going all the way back. I don't think Sage has ever "disclaimed" problems or issues in the beta, paid or not. But paying for the beta doesn't necessarily mean no or reduced issues. Definition:
Beta-software- pre-release software still in the process of development made available to "beta-testers" for the purpose of identifying problems in the application. Because of the nature of beta-software, running such software could potentially cause system-wide problems.

I think in regards for paying for the beta, it was done more for reducing the pirating of the product in beta. If it had to be paid for and was based on officially purchased keys they may be a reduction in that type of hacking. I may be wrong and I think we all know it won't eliminate the problem. But I do think it will go towards reducing it.

Gerry

[ke6guj]

One thing I think needs to be included in the plugin manager is the ability to install, or revert to, an older version of a plugin. There is a plugin that was updated, and the new version is worse, for me, than the older version. But there is no way to get back to the old version that I know of.

[ThePaladinTech]

I wasn't aware there was a max and min version for plugins (I don't make them)

I understand it is a beta, in beta is the time to make these enhancements :) - I also look at is a PUBLIC beta, one that users are allowed to test and help out in the process. I have no problem putting myself at a different (lower) level the plugin developers, but I think I am a valuable beta tester.

I disagree that I should be OK with a post that essentially said this "hey here's a new version, we know it screws this up and if you don't take steps to fix it your system is going to be hosed (steps which you only know about if you read this post) - Testing and Beta in my mind is to discover what doesn't work - not to be unnecessarily exposed to something they know doesn't work. I hope what I am saying here is not misunderstood, I wasn't upset that it broke, I accept it. In fact I gleefully install every update that comes out, and I actually read the posts.* I just think there is a better way to go about this, and that is why I made a suggestion.

No I wouldn't want it to disable everything every time there is a new version...

-BUT- (with everything I have read in all your comments)

I still think there should be a mechanism that 'tests' 'authorizes' the plugins. In my analogy to firefox I seriously doubt that firefox tests every single plugin to verify it works with a new version. but I'm betting if they make a major change to something (like i dunno, say THEMES) they have a way to disable the related plugins. And I know that sometimes they disable items that work just fine in the new version, but they are erring on the side of caution... and making sure that there product has the best chance of a successful upgrade.

They leave the upper version open? Doesn't that defeat having an upper limit? do they only do this while it is in beta?

Perhaps I think the programmers at Sage at more organized then they are? (no disrespect to anyone!) ... But here's how I thought it could be to accomplish what I am talking about without breaking it every time:

1. The Sage programmers know what they will be working on next .. A roadmap
2. Based on this roadmap the sage programmers can tell the sage devs "put in a max version of THIS" (not leaving it open, but a higher rev then current)
3. before a major change like the theme system is rolled out, the Devs are given a shot at it first - in a closed beta (alpha?) program.
3a. determining who is in the closed Beta should be ez - I know who on here is a Dev and who is not, I'm sure Sage does
4. Devs that update there plugins to work with the alpha are given a new max version to put in the manifest
4a. Obviously Devs that abandoned there plugin / aren't around to update it will not and *that* plugin will not get an updated max version.
5. Plugins with a max version lower then the installed version will not show up in the available plugins listing.

Having said all of this another suggested option would be that sage have the ability to disable all plugins of a certain type upon upgrade? Perhaps the same as the tabs that currently exist- General, UI Enhance, UI Replace, Themes. And in the case of 7.12 they could disable all themes?

With Either option perhaps there should be an option to re-enable the disabled plugin, perhaps with a warning "This plugin isn't marked as compatible with this version, perhaps you should check the forums before re-enabling it?"

The main gist of my suggestion was pointed at the often discussed topic of making SageTV appealing to a broader audience. Read Less Technical Folk. FireFox handles this with there plugin system, and I think the Sage Programmers and Devs are wizards and that they should be able to do something similar :)

* In this case I said to myself "i didn't install any themes, full speed ahead!" Um, I had installed one tiny theme opaque panels - oops.

[ThePaladinTech]

Again, paid or not, beta is still beta and bugs and issue are a part of it. Given that, the core of Sage 7 is stable. But a beta reaches a point where it needs to go on more disparate systems to ensure stability. I think we have all become spoiled with the level of stabiltiy that Sage provides. I expect updates and changes to possibily break or cripple something. I would be fooling myself if I didn't. Sage is also quick to correct and work with the public beta users. You pays your money and you takes your chances. But make sure you go into this with your eyes wide open. WHen I paid for this beta I expected nothing different than what I had received from previous public betas. Same quality whether I paid for it or not.
Gerry

I agree with all of that. My exception is while I expect it to break things it would be nice if they had a way to prevent breaking things they know about... to me beta is the unknown aspect. the change to the Themes was a known thing, a known problem. They knew this major change to the theme system was going to break things. They told us so, Which is good, but BETTER would be avoiding it altogether.

[ThePaladinTech]

Ugh and I see the hole in my idea... but the idea remains. And I believe they can make it happen! I'm a concept person not a details person :p

(the manifest is on my machine right? so even if the dev updates it, *MY* manifest will be old and it won't work?)

[GKusnick]

Correct, there is no mechanism by which plugin devs can remotely lift MaxVersion restrictions on end user installations. The only option in that case would be for the dev to release a new version of the plugin with different restrictions, and for end users to upgrade their installed plugins to the new version. This just makes more work for everybody in the (hopefully common) case when nothing is actually broken.

The proper use of MaxVersion, in my opinion, is for cases when you know in advance with high certainty that a feature you depend on is going away in some known future version of Sage. This happens very rarely, so the use of MaxVersion should be correspondingly rare.

The Sage devs do have private betas for a small group of key testers at the start of every beta cycle. (That's why the first public version of V7 was 7.0.9.) But I don't think it's practical for them to do a private release of every subsequent beta build to make sure that all plugins continue to work. It's certainly not practical for them to do any plugin testing themselves.

Users already have the option to disable malfunctioning plugins. If the malfunction is minor and doesn't impair the plugin's function much, users can choose to leave it enabled and live with the weirdness until a new version is available. This also allows end users to participate in plugin testing and warn plugin devs (and each other) of issues. Forcibly disabling plugins on upgrade would take away user choice and put all the burden of testing on the plugin devs. I don't see that as a net benefit for anyone.

The key thing to remember about plugins is that there are no guarantees and you use them at your own risk. If you're not comfortable with the idea that a new release of Sage may break your favorite plugin, then maybe plugins aren't for you.

[PLUCKYHD]

The key thing to remember about plugins is that there are no guarantees and you use them at your own risk. If you're not comfortable with the idea that a new release of Sage may break your favorite plugin, then maybe plugins aren't for you.

Agreed also remember the plugins are created on people's free time and mostly they are sharing things they like on their sage system. Also the plugin system while not perfect was created by demand of users and is worlds better than the old system where there was no plugin and you had 20 different things to download to get one thing working.

[GKusnick]

I should add that I do think there would be value in some sort of Safe Mode to cover the (hopefully rare) case where a plugin crashes Sage before the user can get to the plugin manager screen to disable it.

In principle this would be easy to implement: just set a Safe Mode flag in the properties file at the start of plugin initialization, and clear it again when the Main Menu comes up. A crash in between those two points will leave the flag set and tell Sage to disable all plugins the next time it starts.

It also might be useful to be able to invoke Safe Mode from the command line. The installer could then put a Safe Mode icon in the SageTV Start Menu group alongside the regular SageTV icon.