Plugin design & development lifecycle

 

Plugins will be worked on based on the current prioritization (see the prioritized list and the prioritization process).  Once it is determined that a plugin will be implemented, the first step is to fill out the design docs, including visual design, functional specifications and suggested markup and accessibility concerns here on the wiki.  Once the docs are filled out, development will begin in a dev branch.  Tests should be written prior to implementing features.  Additional design discussions will take place as needed during the development cycle (it is expected that even mature plugins will require further design based on continued feedback from the community).  When the plugin is complete enough to be usable, it can be moved into trunk.

 

A plugin may be usable and stable with only a subset of the desired features.  In many cases it will make sense for a plugin to be released with a core set of features and then have other planned features added in future releases.  While it is preferable to design and document the plugin as much as possible prior to implementation, it is not necessary for the implementation to fulfill all of the written docs before being considered for release.  However, any plugin being considered for release cannot violate any of the terms in the docs.

 

At a high level, there are three buckets that we organize a plugin into during its life cycle:

 

1. Labs: Experimental place for new plugins, contributions or experimental ideas that are not in our current set of priorties but are still under development. These can be very free-form or just early versions of planned plugins. This code lives in /branches/labs/.

    

2. Alpha: These are the set of prioritized plugins currently under active development by the team. Once these plugins are deemed to be close enough to be released, they will be planned for a specific release and moved to trunk as part of the official release. These live in /branches/dev/ and are kept in sync with trunk.

    

3. Official: These plugins are part of the official, supported set of jQuery UI plugins with the full suite of documentation, tests, and demos.  Feature requests and bug reports are managed in Trac. These are versioned as the full library, not individual plugins, and follow our beta > release candidate > final development phases. These files live in /trunk/.

 

The readiness of a plugin will be determined collectively by the team leads.  This process should include a fairly rigorous review from all team leads to ensure we can maintain high quality releases.

 

 

Release schedule 

We will push releases every Wednesday, alternating between stable releases and preview releases.  The majority of work will be put into the preview release with select bug fixes being backported to the stable release branch.  This will allow us to spend the majority of our time on the preview release while providing a steady flow of bug fixes for the stable release. No plugin will be moved from the dev branch to the trunk until it meets the same level of readiness as demonstrated by 1.7 final, in terms of design, specs, development, testing, documentation, and demos.  This is true of major refactorings (of existing components) as well. They should be done in a dev branch, leaving the previous version in the trunk until the refactor is complete.

 

 

Development branches

• /branches/dev/ should contain team-prioritized plugins under active development. Richard will keep these regularly merged up to the trunk
• All work on non-prioritized plugins should be in /branches/labs/
• Plugins in /branches/labs/ do not have the same requirements and restrictions as those in /branches/dev/. They also aren't managed or kept in sync with trunk by the team. This is the reason for this separation. The extra level provides a filter for plugins that are worth the time and effort to maintain the branches by a team lead. If anyone wants to maintain an individual branch, that's up to that individual.
• Preview releases will be done out of /branches/dev/ **need a term other than preview**

 

 

 

1. Labs (new, non-priority, experimental)

 

The Labs is a a free canvas to explore new interactions and widgets that can be part of the overall uber list of widgets here on the wiki or can be a completely creative experiment that isn't on our radar but it worth exploring. The labs can also be a place for developers to work on plugins that aren't currently prioritized or that are recently contributed to the library. The labs are not bound to any release schedule or specific requirements.

 

If a labs plugin is considered stable enough by the labs team, it can be proposed for a future release and upon acceptance will be moved into the dev branch or directly into trunk. All labs code is worked on in branches/labs/(plugin name) on SVN.

 

The plan is to eventually add a link to Labs plugins on the public jQuery UI site so we can gather input from the community early on in development and provide a way to get plugins out into the world faster.

 

For a plugin to be put out in the world as a labs, it should ideally include as many of the elements of a standard UI plugin in order to ease the transition from Labs to the main dev branch, but none of these are required, especially if it's highly experimental:

 

• use the widget factory and be consistent with our coding standards
• leverage exisiting core methods and utilities (position, overlay, shadow)
• use the jQuery UI CSS framework and be ThemeRoller-ready
• work in all our supported browsers (IE 6.0+, FF 2+, Safari 3.1+, Opera 9.0+, and Google Chrome)
• use progressive enhancement and HTML 5 attributes and semantic markup

 

It must have at a minimum:

1. a design wiki planning page (this site) with a description filled out so people can understand the goals and purpose of the plugin or example and we can collect feedback and ideas via the comments
2. at least one demo page. The best practice is to have a self-contained, lightweight flolder with static html demos pages, any scripts and css files. If possible, make your plugins ThemeRoller-ready and include the theme switcher widget. You can link to the Google code view of SVN like this version for spinner on the wiki page.

 

 

 

2. Alpha (Prioritized, active development)

 

An alpha plugin is prioritized and part of our development focus. These plugins are developed in /branches/dev/ but are not tied to a specific release until they are moved into trunk. The plan is to eventually add a link to Alpha plugins on the public jQuery UI site so we can gather input from the community early on in development and provide a way to get plugins out into the world faster. These preview plugins could be presented as a simple link to the demo page(s) and a link to the design wiki planning page for comments.

 

For a plugin to be put out in the world as a preview/labs/alpha, it must:

 

• use the widget factory and be consistent with our coding standards
• leverage exisiting core methods and utilities (position, overlay, shadow)
• use the jQuery UI CSS framework and be ThemeRoller-ready
• work in all our supported browsers (IE 6.0+, FF 2+, Safari 3.1+, Opera 9.0+, and Google Chrome)
• use progressive enhancement and HTML 5 attributes and semantic markup
• ideally already have ARIA attributes and other accessibility features (not required but recommended)

• be reviewed and have input integrated by the design, code and documentation team leads

 

And it must have at a minimum:

1. a detailed design wiki planning page (this site) with description, design and functional specs filled out to match the implemented code. Tech specs must detail dependencies, options, methods.
2. at least one demo page showing default functionality, ideally 1-2 additional demos showing popular options and variations to show the range of the plugin. This can simply be a link to the Google code view of SVN like this version for spinner

 

Open questions:

• are NOT supported by the team like official plugins so should we allow Trac tickets for preview plugins or just ask people to log questions, suggestions or bugs as comments to the wiki page? Leaning towards no Trac, just wiki comments for feedback at thsi stage.
• It would be convenient to offer a downloadable zip of the individual demo folder for a preview plugin to make it easy for people to grab the code but we could skip this feature if it's too hard to maintain with SVN.

 

 

 

3. Official (Beta/Release Candidate/Final)

 

These are official plugins that are part of the suite development process and live in trunk. Once a plugin is part of the official release, it is versioned and released as part of the whole library, not as an individual plugin. The official plugins live in trunck and follow these phases for each release:

 

Alpha:

The alpha phase starts immediately after a final release.  This is the only phase in which new plugins may be added.  During this phase, plugins are still under active development and not feature complete or ready for consumption by the general public.  Features, enhancements and bug fixes occur during this phase, as well as any major refactoring of existing plugins. Alpha code is worked on in  branches/dev/ on SVN.

 

Beta:

Plugins are complete enough for external testing.  Plugins should be feature complete, but may have known limitations or bugs.  During this phase, features and enhancements may be added based on user feedback.  If we tend to be making major changes during the beta phase, this should be an indicator that we're not doing a good job of designing and polling the community prior to development.  The primary focus during the beta phase is bug fixes, performance improvements and robustness. Beta code is worked on in the SVN trunk.

 

Release Candidate:

The release candidate phase may begin any time after all blocker tickets have been resolved.  Ideally there will be no open critical tickets.  Once this phase begins, no new development may occur.  The only changes allowed during this phase are bug fixes and even those should be limited to critical and blocker bugs.  Fixing major bugs is allowed if the changes are small enough and the risk of breaking something else is low enough. Release candidate code is worked on in the SVN trunk.

 

Final Release:

The final release isn't actually a phase, since it only lasts as long as it takes to perform the actual release.  The final release should be done when the team feels confident that there are no more known serious bugs (all blockers and criticals have been resolved). Final release code is worked on in the SVN trunk.

 

For a plugin to be released as a fully supported official jQuery UI plugin (a move to trunk), it must:

 

• use the widget factory and be consistent with our coding standards
• leverage exisiting core methods and utilities (position, overlay, shadow)
• use the jQuery UI CSS framework and be ThemeRoller-ready
• work in all our supported browsers (IE 6.0+, FF 2+, Safari 3.1+, Opera 9.0+, and Google Chrome)
• use progressive enhancement and HTML 5 attributes and semantic markup
• have ARIA attributes and other accessibility features, review by a11y group
• be reviewed and approved by the design, code and documentation team leads

 

And it must have: 

1. a detailed planning wiki page with all sections completely filled out to match the implemented code
2. a set of at least 2-3 demo pages showing default functionality, and popular options and variations to show the range of the plugin - see Tabs demo pages
3. unit and visual tests for all key features (minimum 70% coverage?) - see Tabs visual and unit test examples
4. be added as a plugin category to Trac for issue tracking 

 

Before a RC release, it must also have:

1. fully vetted documentation page on the jQuery MediaWiki page with the overview & dependencies, options, events, methods, theming (all docs tabs) completely filled out and proofread - see Tabs doc page example
2. have a corresponding documentation & demos page on the jQuery UI site - see Tabs demos &  docs page example, also need to add links to the docs & demos landing page and left nav files

 

---

 

Open issues being discussed

 

Scott González: other things to consider: docs, demos, themes, web site updates   

---