TopicStructureForFoswikiExtensionsTalk

i've added a link to the Development topic from Tasks.Component. now you can reach the download, support, and development pages from each plugin's main page in Tasks.

which TopicClassification should the Development topic be set to? i've been using "BrainStorming", tho i don't feel any of them are a great fit. or should it not have a form at all? i'm using "BasicForm" currently.

BuildContrib should be enhanced to automatically create these topics if they don't exist (i will do that)

i have updated the examples above for included files so that passing the plugin name as a parameter is no longer necessary, though it makes me wonder if we should be using VIEW_TEMPLATE and/or PageTypes, though that can be done later---this is an excellent first (second?) step in structure.

-- WillNorris - 13 Mar 2009

Good work. We might need a redirect from http://foswiki.org/Extensions/xxxDev to the right place for those having foswiki plugins installed with a Dev url in the docu.

A client of mine was already complaining that there were no Dev topics any more and no obvious equivalent on foswiki.org. He said: most of his knowledge has been derived from the Dev topics, and Dev topics being the real value of tmwiki.org. So there's great potential in getting the Dev-topics thing right now, although I am not so sure that the old setup was so wrong. Well there are many ways to do it with no obvious gold path. Depends on how easy different requirements are satisfied.

-- MichaelDaum - 17 Mar 2009

On Support.Extensions a create link is displayed if the support topic does not exist, which makes it very easy to create the page and is probably why there are support pages for every extension. If the same thing can be done for the development pages then im sure they will get created very quickly. Would be complimentary to enhancing BuildContrib.

-- AndrewJones - 17 Mar 2009

> We might need a redirect from http://foswiki.org/Extensions/xxxDev to the right place for those having foswiki plugins installed with a Dev url in the docu.

Indeed, I got lost in this process, and kept ending up in the Tasks area.

I changed the wording in the tasks area so feature requests would end up there.

I think this is better than long (tm)wiki Dev-style in Development.

> CDot: Personally I found the Dev topics on (tm)wiki.org just filled up with support requests, and rarely had good stuff
> CDot: and when good stuff did appear, the authors usually raise a task anyway!

Y, well we have bad tasks requests, and we just answer as "not relevant" etc. Having an almighty Dev topic for feature requests is horrible. The discussion about development, well, we could have a Singleton Roadmap topic for each Extension

> CDot: not sure I could write a roadmap for the extensions I work on. Most of the time, new features on the extensions are demand-driven by people who want features and are prepared to pay

-- MartinCleaver - 16 Apr 2009

i added a new TopicClassification: ExtensionsDevelopment per Micha's suggestion. the following topics need to be updated (which i can do) after we have agreement that ExtensionsDevelopment is acceptable.

root@foswiki ...oswiki.org/trunk/core/data/Development # ls -1 *{Plugin,Contrib,AddOn}.txt
AliasPlugin.txt
AttachLinkPlugin.txt
AutoViewTemplatePlugin.txt
BlackListPlugin.txt
BreadCrumbsPlugin.txt
BugsContrib.txt
ChartPlugin.txt
CommentPlugin.txt
CompareRevisionsAddOn.txt
EditChapterPlugin.txt
EditSyntaxPlugin.txt
ExcelImportExportPlugin.txt
ExtendedWebListPlugin.txt
FilterPlugin.txt
FlexWebListPlugin.txt
GenPDFAddOn.txt
GluePlugin.txt
GoUptoTocPlugin.txt
GoogleAnalyticsPlugin.txt
HolidaylistPlugin.txt
HowToMakeSimplePlugin.txt
ImageGalleryPlugin.txt
JQueryLibPlugin.txt
MediaWikiTablePlugin.txt
NatEditPlugin.txt
NewUserPlugin.txt
OpenSourceProjectInAWebContrib.txt
PhpBB3UsersContrib.txt
PreInstallNatEditContrib.txt
RenderFormPlugin.txt
RevCommentPlugin.txt
RevisionLinkPlugin.txt
SendEmailPlugin.txt
SmartEditContrib.txt
SpreadSheetPlugin.txt
ThumbnailPlugin.txt
TimeTablePlugin.txt
VarCachePlugin.txt
WysiwygPlugin.txt
X509UserPlugin.txt

-- WillNorris - 17 Apr 2009

Please have a detailed look at http://extensions.joomla.org/

-- MichaelDaum - 21 Apr 2009

For years, (tm)wiki as in denial that extensions would ever be released in more than one version. Over time we have seen that this is too restrictive. There are clear cases where an extension has to leverage new APIs, work in a different environment, and needs to be released in multiple versions.

At the moment, our extensions repository only allows for one version of an extension to exist. The published documentation relates to that one version. This just isn't good enough.

The players

• Alice Admin, the end user of an extension. All Alice wants is a list of the extensions that are compatible with her version of Foswiki, and a single-click download and install.
• Boris Browser, the person considering installing Foswiki, or who is interested in what is available for their current version, browsing Foswiki.org
• Cathy Compatibility, the extension developer who doesn't care much what rev of Foswiki they are using, they just want to use the basic API, dev and upload, and have their extension published so it's accessible the same for all versions of the core.
• Dan Dangerous, who works at the bleeding edge of Foswiki (and web development generally). Dan wants to access and use the very latest features, and is unlikely to be able to (or want to) maintain compatibility between successive core releases

WIBNIF

• Alice was able to Find more extensions and only see those extension versions compatible with her installed Foswiki
• Boris could select the core version from the foswiki.org interface
• Cathy could use perl build.pl upload with defaults, and not need to worry about compatibility
• Dan could be automatically given the right release area, perhaps based on branch naming
• Extensions web continues to work exactly as it does today i.e. showing the versions of extensions that are compatible with the latest release Foswiki
• Boris could choose to browse the "bleeding edge" extensions to get a feel for what they will get if they wait for the next core release

-- CrawfordCurrie - 30 May 2010

Good scenarios.

Did you want to separate release quality (stable, testing, experimental) from the target foswiki family (Release01x00, Release01x10, trunk). I assume that's what you meant by the "Dan" character?

For release quality, perhaps it is acceptable to continue to have Extensions and Extensions/Testing. Drupal doesn't do more than this: truly "experimental" users can svn checkout from trunk if they are that adventurous. Browsing their stuff, you seem to get:

• Latest release available for each major Drupal release
• Latest development release available for each major Drupal release

And installing a version that isn't the latest, is supposed to be reasonably trivial.

Decisions, issues:

• Do we always assume that "branches of a plugin" are always aligned with svn.foswiki.org Foswiki ReleaseXXxYY branching? Eg. That we will always keep JQueryPlugin unique to Foswiki 1.0.x in branches/Release01x00? OR should "plugin branches" potentially be more abstract and arbitrary - potentially not even being checked into svn.foswiki.org? (eg. plugin developed on sf.net, github, etc)
• A "Release01x00" branch of a plugin might be marked as compatible with Foswiki 1.1.x. But Foswiki 1.1x also has available to it the more recent Release01x10 branch of a FooPlugin. How do we present these multiple choices for the same plugin name to a Foswiki 1.1 (and future versions) user?

So, for the foswiki.org/Extensions web concerns, I am in favour - as Crawford mentioned on IRC - of the foswiki.org/Extensions/FooPlugin topic being a "gateway topic". Probably, there would be a VIEW_TEMPLATE to incorporate a drop-down list to select the foswiki release you're working with so that you get the system topic you would see if you installed the version compatible with the foswiki release specified. Hopefully too, for configure, visiting FastReport with the appropriate URLPARAMs gets you only the extensions you're compatible with.

The choice seems to be: have Extensions/Release01x00, Extensions/Release01x10 subwebs, or something else.

"Something else" proposal

• FooPlugin (gateway topic)
  • FooPluginRelease01x00 (release topic)
    Metadata:
    • PluginTopic: FooPlugin
    • Version: 4096 (2009-03-21)
    • FoswikiCompatible: >=1.0.6, 1.1
    • FoswikiIncompatible: 1.0.8
    • DemoUrl: ...
    • DevelopedInSVN: (should be a URI to where it's developed, perhaps)
    • ...
  • FooPluginTrunk (release topic)
    Metadata:
    • PluginTopic: FooPlugin
    • Version: 8192 (2011-02-23)
    • FoswikiCompatible: 1.1
    • DemoUrl: ...
    • DevelopedInSVN (should be a URI to where it's developed, perhaps)
    • ...

All that's needed is for FastReport to be passed a URLPARAM for the Foswiki version of interest, so that configure is only listing compatible extensions.

The only downside, is that Foswiki 1.0.9 users will see FooPluginRelease01x00 as the extension name instead of FooPlugin (I'm assuming we can teach the Foswiki 1.1 via FastReport to display plugin name instead of plugin's topic name).

Ah, and we'll need more magic in build.pl upload, to ask the name of the plugin branch you're releasing (Eg. trunk vs Release01x00 vs scratch vs 02x00....)

-- PaulHarvey - 30 May 2010

Okay, there's major problems with the proposal above:

• Concept of "latest" is hazy (inconsistent data in our version/release fields)
• Even if we had solid date/revision info, how to decide that FooPlugin 3.3 released 2 months ago which is Foswiki 1.1.x-only is still the only proper choice when faced with a more recent FooPlugin 2.3 (Foswiki 1.0.x + Foswiki 1.1.x compatible) release uploaded yesterday

GeorgeClark and SvenDowideit mentioned a much saner solution for Foswiki 1.1:

• Extensions continues to hold all plugins
• Extensions/Release01x00 contains 1.1-specific releases
• We make the repo order foswiki.org/Extensions, foswiki.org/Extensions/Release01x10 so that something like JQueryPlugin could have a dual life in both webs - but always ultimately take the Release01x10 subweb for updates to that plugin
• Make a configure checker for Foswiki 1.1 that warns if you don't have the Extensions/Release01x00 in your repo list (to cater to upgraders)
• Make new releases of JQueryPlugin (and other 1.1-only plugins) in Extensions/Release01x00 Extensions/Release01x10

-- PaulHarvey - 31 May 2010

And on each subsequent core release we add the new repo to the repo path? What happens if a plugin for Release01x01 no longer works on Release 02x00, because the author did something stupid and called a core API?

I don't understand the last point in the bullet list above.

• Make new releases of JQueryPlugin (and other 1.1-only plugins) in Extensions/Release01x00

What is the point of making releases of 1.1-only extensions in a 1.0 repository? It was a typo -PH

I don't have a problem with the subweb solution, as long as the browser (non-configure) requirements are also met.

-- CrawfordCurrie - 31 May 2010

I think we all agree that the Extensions/Release0XxY0 approach is not satisfactory. However it is probably the only feasible way forward for the 1.1 schedule, unless we want to delay a few months.

I hope we don't have to have a Extensions/Release02x00 subweb. I would hope that we have some smarter configure UI to allow the user to pick whichever release of a plugin they want, and hide incompatible releases from them, and for bonus points, highlight the dependencies that would be pulled in.

-- PaulHarvey - 31 May 2010

see also FormallySupportMultipleExtensionVersions for some discussion on organization of extensions, dependencies, and multiple version support. The topic needs some rework.

-- GeorgeClark - 31 May 2010