Release management

There's no formal "release process" defined, but here's the simple guideline of how we get contributions merged and make a new release.

Core

We have a Plack "core" team who is responsible for merging (or NOT merging) contributions from the community, and they have commit bits on the main Github repository.

• Tatsuhiko Miyagawa (Release manager)
• (TBA)
• (TBA)
• (TBA)
• (TBA)

Merging patches

Once issues and pull requests are opened on the issue tracker, one or more of the core team should respond to them by expressing approval (+1) or denial (-1), or neutral (-0). If the patch needs to be updated because of violation of styles or lack of unit tests, it should be expressed so and bounced back to the original contributor's responsibility to update the patch accordingly.

Making a release

One of release managers will make a new release a new version to CPAN off of "master" git branch when a) all "blocker" issues are clear on the issue tracker and b) all the unit test passes.

Ideally, the master branch should be always ready to be released by not merging branches or pull requests that break either assumption.

Policies

These are not hard policies, but the core team should try as hard as possible to follow the following policies, and it needs to be discussed when the breaking changes are to be introduced.

• Dependencies should be kept minimal and all mandatory dependencies should be in pure perl
• Minimal supported perl version is 5.8.1 as of 2012. We'll upgrade it once majority of downstream frameworks have abandoned it.
• More code means more bugs and could lead to technical debts in the future. If proposed features can be implemented outside core (like Middleware), it should be done so.
• We use Module::Install as a build tool as of 2012. This is a personal preference of the original author, so he is all to blame if you dislike it :) Using more sophisticated tools (such as dzil) could raise the bar of contributing a bit too high as of this writing. This can be rethought as the ecosystem gets more mature.
• Plack/PSGI should be kept as frameworks neutral as possible. Any favoritism in the code base should be avoided i.e. "Just to make framework X happy" or "Make things less broken on PaaS Y" doesn't justify a new change, unless the change is also beneficial to other frameworks/environments.