Dancer::Development man page on Pidora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Pidora logo
[printable version]

Dancer::Development(3)User Contributed Perl DocumentatioDancer::Development(3)

NAME
       Dancer::Development - guide for developers interested in contributing

DESCRIPTION
       This guide has been written to help anyone interested in contributing
       to the development of Dancer.

       First of all - thank you for your interest in the project!  It's the
       community of helpful contributors who've helped Dancer experience
       phenomenal growth to get to where it is today.

       Please read this guide before contributing to Dancer, to avoid wasted
       effort and maximizing the chances of your contributions being used.

WAYS TO CONTRIBUTE
       There are many ways to contribute to the project. Dancer is a young yet
       active project and any kind of help is very much appreciated!

   Publicity
       You don't have to start by hacking the code, spreading the word is very
       valuable as well!

       If you have a blog, just feel free to speak about Dancer.

       If you're a Twitter user, you can tweet about it with the hashtag
       "#perl" (and feel free to follow @PerlDancer for news and updates on
       Dancer!).

       Of course, it doesn't have to be limited to blogs or Twitter.  Feel
       free to spread the word in whatever way you consider fit and drop us a
       line on the Dancer user mailing list noted below.

       Also, if you're using and enjoying Dancer,
       http://cpanratings.perl.org/dist/Dancer, explaining what you like about
       Dancer is another very valuable contribution that helps other new users
       find us!

   Mailing list / IRC community
       Subscribing to the mailing list and/or hanging out on our IRC channel
       and providing assistance to new users is incredibly valuable.

       ·   Mailing list:
	   http://lists.perldancer.org/cgi-bin/listinfo/dancer-users
	   <http://lists.perldancer.org/cgi-bin/listinfo/dancer-users> to
	   subscribe or view archives

       ·   IRC: "#dancer" on "irc.perl.org", or
	   <http://www.perldancer.org/irc> for a quick web client.

   Documentation
       While we value documentation very much, it's difficult to keep it up-
       to-date.	 If you find a typo or an error in the documentation please do
       let us know - ideally by submitting a patch with your fix (see "Patch
       Submission").

   Contribute to CPAN Testers
       If you have access to perl on rare operating systems, please consider
       contributing tests. See
       <http://wiki.cpantesters.org/wiki/TestDuringInstall> for more
       information.

   Code
       You can write extensions (plugins) for Dancer extending Dancer's core
       functionality or contribute to Dancer's core code, see "Patch
       Submission" below.

GENERAL DEVELOPMENT GUIDELINES
       This section lists high-level recommendations for developing Dancer,
       for more detailed guidelines, see "Coding Guidelines" below.

   Quality Assurance
       Dancer should be able to install for all Perl versions since 5.8, on
       any platform for which Perl exists. We focus mainly on GNU/Linux (any
       distribution), *BSD and Windows (native and Cygwin).

       We should avoid regressions as much as possible and keep backwards
       compatibility in mind when refactoring. Stable releases should not
       break functionality and new releases should provide an upgrade path and
       upgrade tips such as warning the user about deprecated functionality.

   Quality Supervision
       We can measure our quality using the CPAN testers platform:
       <http://www.cpantesters.org>.

       A good way to help the project is to find a failing build log on the
       CPAN testers: <http://www.cpantesters.org/distro/D/Dancer.html>

       If you find a failing test report, feel free to report it as a GitHub
       issue: <http://github.com/sukria/Dancer/issues>.

   Reporting Bugs
       We prefer to have all our bug reports on GitHub, in the issues section:
       <http://github.com/sukria/Dancer/issues>. It's possible though to
       report bugs on RT as well:
       <https://rt.cpan.org/Dist/Display.html?Queue=Dancer>

       Please make sure the bug you're reporting does not yet exist. In doubt
       please ask on IRC.

   Patch Submission
       The Dancer development team uses GitHub to collaborate.	We greatly
       appreciate contributions submitted via GitHub, as it makes tracking
       these contributions and applying them much, much easier. This gives
       your contribution a much better chance of being integrated into Dancer
       quickly!

       To help us achieve high-quality, stable releases, git-flow workflow is
       used to handle pull-requests, that means contributors must work on
       their "devel" branch rather than on their "master".  (Master should be
       touched only by the core dev team when preparing a release to CPAN; all
       ongoing development happens in branches which are merged to the "devel"
       branch.)

       Here is the workflow for submitting a patch:

       ·   Fork the repository <http://github.com/sukria/Dancer> (click
	   "Fork")

       ·   Clone your fork to have a local copy using the following command:

	       $ git clone git://github.com/myname/Dancer.git

       ·   As a contributor, you should always work on the "devel" branch of
	   your clone ("master" is used only for building releases).

	       $ git remote add upstream https://github.com/sukria/Dancer.git
	       $ git fetch upstream
	       $ git checkout -b devel upstream/devel

	   This will create a local branch in your clone named "devel" and
	   that will track the official "devel" branch. That way, if you have
	   more or less commits than the upstream repo, you'll be immediately
	   notified by git.

       ·   You want to isolate all your commits in a topic branch, this will
	   make the reviewing much easier for the core team and will allow you
	   to continue working on your clone without worrying about different
	   commits mixing together.

	   To do that, first create a local branch to build your pull request:

	       # you should be in devel here
	       git checkout -b pr/$name

	   Now you have created a local branch named pr/$name where $name is
	   the name you want (it should describe the purpose of the pull
	   request you're preparing).

	   In that branch, do all the commits you need (the more the better)
	   and when done, push the branch to your fork:

	       # ... commits ...
	       git push origin pr/$name

	   You are now ready to send a pull request.

       ·   Send a pull request via the GitHub interface. Make sure your pull
	   request is based on the pr/$name branch you've just pushed, so that
	   it incorporates the appropriate commits only.

	   It's also a good idea to summarize your work in a report sent to
	   the users mailing list (see below), in order to make sure the team
	   is aware of it.

	   You could also notify the core team on IRC, on "irc.perl.org",
	   channel "#dancer" or <http://www.perldancer.org/irc>.

       ·   When the core team reviews your pull request, it will either accept
	   (and then merge into devel) or refuse your request.

	   If it's refused, try to understand the reasons explained by the
	   team for the denial. Most of the time, communicating with the core
	   team is enough to understand what the mistake was. Above all,
	   please don't be offended.

	   If your pull-request is merged into devel, then all you have to do
	   is to remove your local and remote pr/$name branch:

	       git checkout devel
	       git branch -D pr/$name
	       git push origin :pr/$name

	   And then, of course, you need to sync your local devel branch with
	   the upstream:

	       git pull upstream devel
	       git push origin devel

	   You're now ready to start working on a new pull request!

About the Release Cycle
       Since version 1.2, the team has decided to take a step further toward
       production concerns: Dancer now promises to provide an API-stable and
       feature frozen release, whose updates will only be about bugfixes and
       documentation updates.

       After some discussion with the core-team members, it has been agreed
       that the 1.2xx release series will be the first of this kind, and will
       live as long as 1.3xx lives.

       As soon as the last 1.3xx release is mature enough and the core team is
       happy with, it will be uploaded as the first version of the 1.4xx
       series, and 1.2xx will become obsolete.

       This lets us evolve quickly in our main track (devel in GitHub will
       contain all the daily work we want to make 1.3xx better) but as well,
       it lets us assure maintainability for the 1.2 series, as we will
       probably have to fix a bug somewhere in 1.2 without merging with new
       stuff contained in the devel branch.

       That's why a maintenance branch is added to the repo. To be very clear,
       this branch is named "frozen", to reflect the idea that the source-code
       in this branch is not meant to evolve regarding features.  It should
       only contains fixes for bug or documentation updates.

       If you want to submit a pull-request to the frozen branch (that means
       1.3xx is out and you've found a bug in 1.2xx) you need to base your
       work on the "frozen" branch. Use the same procedure explained before,
       but with the "frozen" branch.

RESOURCES FOR DEVELOPERS
   Mailing Lists
       A mailing list is available here:
       http://lists.perldancer.org/cgi-bin/listinfo/dancer-users
       <http://lists.perldancer.org/cgi-bin/listinfo/dancer-users>

   IRC Channels
       You can reach the development team on irc.perl.org, channel #dancer or
       via a web chat interface at <http://www.perldancer.org/irc>.  We're
       always happy to hear from users and contributors.

   Repositories
       The official repository is hosted on GitHub at the following location:
       <http://github.com/sukria/Dancer>.

       Official developers have write access to this repository, contributors
       are invited to fork it if they want to submit patches, as explained in
       the Patch submission section.

       The repository layout is organized as follows:

       ·   "master"

	   This branch is dedicated to prepare CPAN releases. We push to that
	   branch only for packaging a new release. Every CPAN version are
	   made from this branch.

       ·   "devel"

	   This is the development branch. New features are pushed here, and
	   will be merged to master when the next release is being prepared.

CODING GUIDELINES
       This section describes standards and requirements for coding. For more
       broad guidelines, see "GENERAL DEVELOPMENT GUIDELINES" above.

   About Dependencies
       Dancer is intended to be a micro-framework. That means among other
       things that it should remain lightweight. For this reason we try very
       hard to keep the dependencies as low as possible. On the other hand, we
       don't want to reinvent the wheel either.

       We not likely to accept a new dependency to the core unless there is a
       very good reason.

       If a patch provides a new feature that depends on a module, the
       solution is to perform a dynamic loading. Dancer has a class dedicated
       to that job: Dancer::ModuleLoader. Here is an example of how to use it:

	   package Dancer::Some::Thing;
	   use Carp;

	   sub init {
	       Dancer::ModuleLoader->load('Some::Deps')
		   or croak "the feature provided by Dancer::Some::Thing needs Some::Deps";
	   }

       That way, an optional feature doesn't block Dancer from being installed
       since the dependency check is performed at runtime.

   Perltidy
   Tests
RELEASING
   Public Releases
       Public and stable releases are those without an underline ('_') in the
       version number. The latest stable release can be downloaded from CPAN
       and github.com.

   Developer Releases
       Developer releases are those which include an underline ('_') in the
       version number. Whenever the devel branch has been merged into the
       master branch, the CPAN release built must be a developer version (the
       version number contains a '_').

       Before a new release is made, the uploaders must wait for the CPAN
       testers reports. This is done to make sure the new merge doesn't bring
       regressions.

   Roadmap
       For current information on Dancer's plans for the future, see the file
       TODO at <https://github.com/sukria/Dancer/blob/master/TODO>.

AUTHOR
       This document has been written by Alexis Sukrieh sukria@cpan.org

perl v5.14.1			  2011-07-26		Dancer::Development(3)
[top]

List of man pages available for Pidora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net