From: Dave Rolsky Date: Mon, 5 Oct 2009 18:58:50 +0000 (-0500) Subject: Add details on what goes into making a release X-Git-Tag: 0.93~31 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=6c1fa4adb095b7aae7fc336ea4929237685c70c9;p=gitmo%2FMoose.git Add details on what goes into making a release --- diff --git a/lib/Moose/Manual/Contributing.pod b/lib/Moose/Manual/Contributing.pod index e846041..a30cc0a 100644 --- a/lib/Moose/Manual/Contributing.pod +++ b/lib/Moose/Manual/Contributing.pod @@ -12,6 +12,8 @@ the L is very simple. The general gist is: clone the Git repository, create a new topic branch, hack away, then find a committer to review your changes. +Note that this document applies to both Moose and L development. + =head1 NEW FEATURES Moose already has a fairly large feature set, and we are currently @@ -226,6 +228,38 @@ defend your change. Development releases are made without merging into the stable branch. +=head2 Release How-To + +Moose (and L) releases fall into two categories, each with their +own level of release preparation. A minor release is one which does not +include any API changes, deprecations, and so on. In that case, it is +sufficient to simply test the release candidate against a few different +different Perls. Testing should be done against at least two recent major +version of Perl (5.8.8 and 5.10.1, for example). If you have more versions +available, you are encouraged to test them all. However, we do not put a lot +of effort into supporting older 5.8.x releases. + +For major releases which include an API change or deprecation, you should run +the F script from the L. This script tests a +long list of MooseX and other Moose-using modules from CPAN. In order to run +this script, you must arrange to have the new version of Moose and/or +Class::MOP in Perl's include path. You can install the module, or fiddle with +the C env var, whatever makes you happy. + +The smolder script downloads each module from CPAN, runs its tests, and logs +failures and warnings to a F file. If there are +failures or warnings, please work with the authors of the modules in question +to fix them. If the module author simply isn't available or does not want to +fix the bug, it is okay to make a release. + +Regardless of whether or not a new module is available, any breakages should +be noted in the conflicts list in the distribution's F. + +Both Class::MOP and Moose have a F<.shipit> file you can use to make sure the +release goes smoothly. You are strongly encouraged to use this instead of +doing the final release steps by hand. + =head1 EMERGENCY BUG WORKFLOW (for immediate release) Anyone can create the necessary fix by branching off of the stable branch: