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)
• Tokuhiro Matsuno
• Jesse Luehrs
• Tomas Doran
• Graham Knop

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). The core team can merge a contribution either when there's an enough number of approvals or a compelling proposal with no denial present.

In case of core team not sure of whether the changes are good or bad, it is recommended to summon people with expertises. For example, if the issue was a breakage in combination with existing frameworks, the developers of the framework should be summoned. By mentioning their github names (like @miyagawa) in the issue comment, they are notified via emails.

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 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 and approved by majority of the Core team 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 Milla as a build tool as of 2013. Milla allows the contributing developers to build, test and install the distribution without installing Milla (and all of Dist::Zilla). Only the core developers who makes a release to CPAN will need it.
• 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.
• We prefer correctness over convenience, but at the same time we try not to be too pedantic. "The real world use case" is always important and we trust the core team's responsibility to take a good balance for being pragmatic in such situations.
• Undocumented features are considered unofficial and users should not rely on it.
• When a documented feature is changed or removed, there will be a deprecation period where using the feature raises a warning.