Tags:
create new tag
, view all tags
OBSOLETE - see ExtensionsTestedOnTWiki for test status

This topic lists those plugins that have been tasted with the latest beta (based on the entry in the web form).

As you will see, there are a number of plugins claiming to be tested at the latest beta, but the page shows a modification date long before release of the latest beta. It probably would be better to show the particular beta release that a plugin was tested (e.g., TWiki20040320 for the current "latest" beta) rather than the moving target "Latest Beta". For convenience, I have sorted this table by data of last change to the plugin.

Plugin, description last change:Sorted descending diffs Installed at TWiki.org:
SlideNavPlugin: A slide navigator 2008-12-12 - 12:04 7 - Diffs No
SlidePlugin: Slide presentations 2006-02-16 - 22:02 4 - Diffs No
JSCalendarAddOn: Allows the javascript calendar provided by TWiki:Plugins/JSCalendarContrib to be used for any form. 2005-02-13 - 17:12 3 - Diffs No
WinXPSkinPluginDev: 2003-02-03 - 16:26 8 - Diffs No

-- ThomasWeigert - 18 Apr 2004

Actually, this table shows also Dev pages, skins, add ons, etc. I had tried to limit this to plugins by beginning the search string with [T]opicClassification.*value\.*[P]luginPackage.*= but then no topics were found. After staring at this regular expression for to long I gave up. Any hints are appreciated.

-- ThomasWeigert - 18 Apr 2004

Tthe latest alhpa/beta values are garbage data and should be thrown out. Ditto for the Support web and BugReports

-- MattWilkie - 19 Apr 2004

I agree.

-- MartinCleaver - 19 Apr 2004

May I suggest the following: Let's have a table defining all releases and beta releases of TWiki and use that table to generate a checkbox option for the "tested" entry in the form for Plugins. After every release we delete the beta versions related to that release to keep the checkbox table small. -- ThomasWeigert - 19 Apr 2004

I'd prefer adding a new function to the ever growing TestenvCgiScript which spit out all the bug and support form values in a ready to copy and paste format. -- MattWilkie - 19 Apr 2004

Matt, not sure what you are trying to say... -- ThomasWeigert - 21 Apr 2004

Rather than a picklist in a form or table which somebody needs to update everytime there is a new beta release, I'd like to see testenv or close sibling generate a table in a verbatim block which could be copy and pasted into the plugin page. The same process could be used for a bug report or a support issue. If Crawford's build script turns out to be viable, it could call testenv from the commandline and build that portion of the plugin topic. -- MattWilkie - 22 Apr 2004

Well, let's not delay making the information here more useful by waiting for some future script. Personally, I don't see anything wrong with a simple table that lists all the twiki releases and current beta versions. This can generate the options for the web form. -- ThomasWeigert - 22 Apr 2004

I didn't mean to imply "don't do the forms", I was just putting forward an idea for a possibly) more optimal solution. I'm assuming that adding a verbatim block top testenv's output is relatively simple (roughly equivalent amound of work) being generally ignorant of perl, that may be making an ass of u and me.

-- MattWilkie - 23 Apr 2004

I randomly checked in the (today) most recent updated plugin. It says "latest beta" but that information was added on 14 Jan 2004. Clearly, there have been beta copies thereafter. Now maybe the author has kept the info up to date, but maybe not? Other checks show, e.g., ConditionalPlugin as having "latest beta", but the latest checked in version is before the Beijing release; clearly the "latest beta" must be referring to a beta of the Beijing release, not the Cairo release.

I propose we replace "latest beta" by a concrete version.

-- ThomasWeigert - 21 Apr 2004

Seconded.

-- CrawfordCurrie - 22 Apr 2004

Thirded. also answer inline above

-- MattWilkie - 22 Apr 2004

I have updated the PackageForm as discussed. I also have began to update Plugin topics were it seemed obvious. The rule of thumb I followed was that if a plugin claimed latest beta, select the beta version preceding the date the last version was checked in, unless the "latest beta" was updated after that (as shown in the RCS history), in which case choose that. Where "latest beta" refers to a time before the current release, try to test whether the plugin works on the Beijing release and mark as such, if successful.

I used this heuristics to update all plugins with release dates after the Dec 2003 beta (this is the earliest beta I have any info on).

There are still a few plugins showing "latest beta", but these have all released earlier. The assumption is that these have been tested on some beta after the TWiki release they did get tested on, but before the Dec 2003 beta.

The DefaultPlugin also shows "latest beta", but here I assume that this is really meant, as this plugin is part of the standard release.

Hopefully plugin authors will update their information where missing or incorrect.

-- ThomasWeigert - 16 May 2004

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2007-03-03 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.