Commit | Line | Data |
600f7f85 |
1 | =pod |
2 | |
3 | =head1 NAME |
4 | |
5 | Moose::Manual::Contributing - How to get involved in Moose |
6 | |
7 | =head1 GETTING INVOLVED |
8 | |
9 | Moose is a pretty open project and we are always willing to accept |
10 | bug fixes, more tests and doc patches. Doing these things is as |
11 | simple as cloning a copy of the git repository and hacking away. All |
12 | we ask is that for any non-trivial code patches, you check with one |
13 | of the core developers before applying said patch. |
14 | |
15 | =head1 NEW FEATURES |
16 | |
17 | Moose already has a fairly large feature set and we are currently B<not> |
18 | looking to add any new features to it. If you have an idea for a new |
19 | feature in Moose, you are invited instead to create a MooseX:: module |
20 | of it first. At this stage, no new features will even be considered for |
21 | addition into the core without first being vetted as a MooseX:: module. |
22 | |
23 | But worry not, Moose was built from the ground up with the idea of being |
24 | highly extensible and quite often the feature requests we see can be |
25 | implemented through a couple of small and well placed extensions. Try it, |
26 | it is much easier then you might think. |
27 | |
28 | =head1 TESTS, TESTS, TESTS |
29 | |
30 | If you write I<any> code in Moose or Class::MOP, you B<must> add tests |
31 | for that code. If you do not write tests then we cannot guarantee your |
32 | change will not be removed or altered at a later date. |
33 | |
34 | If your code change/addition is deep within the bowels of Moose/Class::MOP |
35 | and your test exercises this feature in a non-obvious way, please add some |
36 | comments either near the code in question or in the test so that others |
37 | know. |
38 | |
39 | =head1 BACKWARDS COMPATABILITY |
40 | |
41 | Change is inevitable and Moose is not immune to this. We do our best |
87e6fc89 |
42 | to maintain backwards compatability, but we do not want the codebase |
600f7f85 |
43 | to become overburdened by this. This is not to say that we will |
44 | be frivolous with our changes, quite the opposite, it is more to say |
45 | that we are not afraid of change and will do our best to keep it as |
46 | painless as possible for the end user. |
47 | |
48 | The rule is that if you do something that is not backwards compatabile |
49 | you B<must> do I<at least> one deprecation cycle (more if it is larger |
50 | change). For really larger or radical changes dev releases may be needed |
51 | as well (the core developers will decide on this on a case-per-case |
52 | basis). |
53 | |
54 | The preference with regard to deprecation is to warn loudly and often |
55 | so that users will have time to fix their usages. |
56 | |
57 | All backwards incompatible changes B<must> be documented in |
58 | L<Moose::Manual::Delta> and when possible should provide any useful |
59 | tips or workarounds to help smooth the transition process. |
60 | |
61 | =head1 AUTHOR |
62 | |
63 | Stevan Little E<lt>stevan@iinteractive.comE<gt> |
64 | |
65 | =head1 COPYRIGHT AND LICENSE |
66 | |
67 | Copyright 2009 by Infinity Interactive, Inc. |
68 | |
69 | L<http://www.iinteractive.com> |
70 | |
71 | This library is free software; you can redistribute it and/or modify |
72 | it under the same terms as Perl itself. |
73 | |
74 | =cut |