See also the screencast explaining how to setup and create a new distribution with Milla.

Install Milla and setup your profile.

Setup command will ask you a simple question to make a basic profile. If you already have set up dzil before, this is common and you can skip the process.

Now it's time to make a new distribution.

At this point, you will have a really simple Dist-Name directory that contains your module file with as minimum boilerplate as possible.

It is recommended to track your repository under git as soon as possible, even before releasing to CPAN.

Now start writing your code, edit the docs, tests and manage CPAN dependencies with cpanfile.

You can test your code with a simple prove -l t.

For the first time build only, you can make a test build to get some boilerplate you want to keep in the git repository so that your github repository looks great with README, as well as installable from git using cpanm or testable with Travis CI.

When you get confident and it's about time to ship to CPAN, use the test and release command. Before doing so, make sure your git directory is not dirty i.e. all changes are committed.

Milla assumes you have a git remote setup so that you can push all your changes to. I recommend you to use either hub gem or App::ph to create a new github repository.

Now, make sure you have Changes file ready and have a new entry under {{$NEXT}}, which will be expanded to the next version of your module.

And your first release is done. The release is tagged on git and all the changes atomatically made are committed to git as well.

If this is your first conversion to Milla and want to make sure you're not going to mess CPAN with a bad archive when something goes wrong, you can run the releas command with FAKE_RELEASE environment variable. This will run all the other release process, except the UploadToCPAN step.

Wait for PAUSE processing it and your module showing up on MetaCPAN in a few minutes. Congratulations!

You have new features, bugs, pull requests and get ready to make a next version of your module. Great, making a new release is equally easy.

First, make sure all your code has been committed to git and there's no dirty files in the working directory.

Then make sure to edit Changes file and contain entries for the next release under {{$NEXT}}. You don't need to commit the change to the Changes file, yet.

Now, make a release!

The release command will automatically bump the version for you - if you have 0.10, the next version will be 0.11 by default, but you will be prompted to confirm that version in case you need a major bump.

This will update Changes, META.json and bump $VERSION in your mailn module. These changes made by Milla will be automatically committed, tagged and pushed to the remote.

This section describes how to migrate your current authoring process to Milla.

First, move the prereq declaration from Makefile.PL or Build.PL to cpanfile.

The easiest way to convert existing dependencies to cpanfile is to use the command line tool mymeta-cpanfile, which is installed with Module::CPANfile. Run the configuration with Makefile.PL for the one last time, then run the mymeta-cpanfile command:

You can redirect the output to cpanfile if you like. It is important to pass --no-configure option here, since otherwise modules like ExtUtils::MakeMaker will be included. It is not required with Milla setup, since Milla knows which configuration tool (installer) to use and include them in META files upon the releases. You can leave that out from the cpanfile.

If you decide to manually construct new cpanfile, the format is mostly compatible to Module::Install's requirement DSL.

becomes:

which is exactly the same. If you use Module::Build or ExtUtils::MakeMaker, that will be more manual process, but basically the same thing. See cpanfile for the available syntax.

Next, remove unnecessary boilerplate files.

Next, create a new dist.ini with the following two lines:

the name = line is optional.

If your work directory is named Dist-Name, Milla will be able to figure out that is your distribution name, so you can omit that line.

Next, Edit .gitignore and add the following lines:

You're almost done, and your directory will look like:

git add the newly created files and commit it.

Now you're ready to make the first build.

and if it was successful, you get a build in a directory called Dist-Name-v0.1.0 under your current directory. They can be later removed with milla clean command.

Also, new Build.PL, META.json and README.md are added in your working directory for git-friendliness. git add them and commit it.

Now you're ready to roll a new release with Milla. Before doing so, convert your Changes file format a little bit, and make sure you have a following header in the top:

The {{$NEXT}} is a template variable that gets replaced with the version and date string, when you make a next release. This is almost the only change you're required to make in your code base.

Now, run the release command:

to make a new release, in the same way described above for a new Milla setup. You can set FAKE_RELEASE environment variable if this is your first conversion and want to double check what happens, before uploading to CPAN.

When this is not your first release, the version number gets automatically bumped by Milla, but you will be prompted if that is exactly the version you want, and if you want a major version up, you can specify to do so.