Development phases

Page history last edited by Richard D. Worth 4 mos ago

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 specs are filled out, development will begin in a 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 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:

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 at point release milestones.
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 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

Each branch contains team-prioritized plugins under active development. Richard will keep these regularly merged up to master at point release milestones.
All work on non-prioritized plugins should be done in forks not master or branches
Preview releases will be done by merging all topic branches into an integration branch. **need a term other than preview**

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:

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 HTML5 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:

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.
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 live code view like this version for tooltip.

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 the official release, 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:

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.

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