Plugin design & development lifecycle

Plugins will be worked on based on the current prioritization. Prioritization is determined by the team on an on-going basis. 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 specs are filled out, development will begin in a branch. 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 master.

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 specs before being considered for release.  However, any plugin being considered for release cannot violate any of the terms in the specs.

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

1. In-Development: 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 master as part of the official release. These live in their own git branches which are synced with master as needed.

    

2. Released: 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 alpha > beta > release candidate > final development phases. These files live in master.

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 

No plugin will be moved from a dev branch to master until it meets the level of quality expected from beta release, in terms of design, specs, development, testing, documentation, and demos.  This is true of rewrites of existing components as well. They should be done in a dev branch, leaving the previous version in master until the rewrite is complete.

Development branches

• Each branch contains team-prioritized plugins under active development.
• All work on non-prioritized plugins should be done in forks, not in the official jquery-ui repo.
• Preview releases will be done by merging all dev branches into an integration branch.

1. In-Development (Prioritized, active development)

An alpha plugin is prioritized and part of our development focus. These plugins are developed in their own branch but are not tied to a specific release until they are moved into master. 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/alpha, it must meet all of our coding standards and have been reviewed by the team leads. It must also have a detailed design wiki planning page (this site) with description, design and functional specs filled out to match the implemented code. There must also be at least one demo page showing default functionality, ideally one or two additional demos showing popular options and variations to show the range of the plugin.

Feedback for in-development plugins should take place on the plugin's wiki page (add wiki comments) or if there isn't room there, threads can be started in the Developing jQuery UI forum. Trac is not used for in-development plugins.

2. Released (Beta/Release Candidate/Final)

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

Beta:

Plugins are complete enough for testing by all users. 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 master.

Release Candidate:

The release candidate phase may begin any time after all blocker tickets have been resolved. 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 blocker bugs and regressions. 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 master.

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 have been resolved). Final release code is worked on in master.

Open issues being discussed

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