Release

Once Padre or one of the plugins is released based on the following process it is uploaded to CPAN.
There are various way Repackaging and Distributing those modules.

Prerequisites to releasing Padre

As the Release Manager you will be uploading the Padre tarball to pause, to ensure you have the
right permissions to do this you must obtain co-maintenance permissions for all of the namespaces in the Padre distribution. Talk to Gábor Szabó (szabgab), Adam Kennedy (Alias), or Steffen Müller (tsee) about this. Make sure you get Wx::Perl::Dialog, Wx::Perl::Dialog::Frame, Wx::Perl::Dialog::Simple, and Wx::Perl::Dialog::SingleChoice? too.

Release of Padre using a branch

In order to allow a few days of stabilization of Padre and to allow the translators to catch up while
allowing everyone else to freely work on the main trunk we release from a branch.

A few (2 or 3) days before the planned release date the release manager creates an svn copy of trunk to branches/release-n.nn.

The high level steps are as follows:

Make sure all tests pass,

Set the release version, commit,

Tidy the project, commit,

Update Changes file, commit,

Rebuild the messages.pot, commit, no longer required

Set the version from current dev to next production release, commit,

Branch

Announce branch and URL to dev list,

Allow a few days for translators,

Build Tar Ball,

Test where you can.

Upload to PAUSE.

Prior to merge back, set version to current dev version ( should be +1 ), commit,

Merge changes on Branch back to Trunk, this should only be the translations if all went well.

Detailed Steps for a Release

Note: All commands are taken as relative to your Padre directory ( the one with Makefile.PL in it )

run perltidy on the trunk ../tools/tidy_project.pl

commit

Update the Changes file, noting the date of the release being the date you start the branch

commit

set the version from the current development version number to the release version number ( should be even numbered for released odd numbers for development )

Note: there is a script in tools that will update the $VERSION string, however PPI::PowerToys? has an awesome ppi_version, use this when you can: ppi_version change old_ver new_ver, ie ppi_version change 0.81 0.82

To complete the final tasks on trunk, update the Changes file by "opening" the next version.

Modify Changes, set the next development version number, this should be odd and the next release version number should be even, ie if you have just branched release-0.82, then changes gets updated with:

0.84 TBA

0.83 Dev - not released.

From this point onwards you switch your working copy between the branch and trunk as needed. To switch between trunk and the branch:

svn switch http://svn.perlide.org/padre/branches/release-X.XX .

then every commit will go to the branch while the plugins are still from trunk

the release can be done here but probably it is better NOT to run the perl tidy on the branch as it will make merging very difficult

Announce the Branch in padre-dev

Announce the branch in the dev mailing list and put out a call for translators, an email template is provided:

Hi Team,

I have just made a branch of trunk for the next Padre release <version>.

Could all translators be so kind as to update their language.

To do so, either check out a working copy of the branch here:

svn co http://svn.perlide.org/padre/branches/Padre-<version>

or alternately you can switch your working copy:

svn switch http://svn.perlide.org/padre/branches/Padre-<version>

Please commit all changes to the branch for inclusion into the next great release of Padre.

Regards,

<name>
Padre Release Manager.

Do the regular release process

The release manager first builds a distribution and when she is sure it creates a good release, she can run the release.pl script again to also tag the release in SVN and then ask others to test it:

the environment variable RELEASE_TESTING should be set to ensure testing for a release is run.

the release.pl script will set it if the variable isn't found. If you want more control over the testing before a release set RELEASE_TESTING to 1 to test, 0 to turn testing off.

run perl ../tools/release.pl --revision REV --version VERSION will try to create a distribution using a temporary directory and copy the resulting Padre-X.XX.tar.gz in the current directory.

Test it by yourself (install it using pip, run it)

run perl ../tools/release.pl --revision REV --version VERSION --tag This will also create a tag in SVN.

Release Manager

Release schedule

The exact release schedule is decided by the current release manager, below are the general guidelines

Padre is released to CPAN about once every week when trunk seems to be in a stable state.

Once a month we set aside a version for a "packaged" release for which we use a longer time on the release branch.

We take the latest regular release and base the "packaged" release right on the regular release.
So for example we have 0.43, 0.44, regular releases then based on 0.44 we create a release branch for 0.45
We give the translators a few days to catch up on this branch. That time will also allow
people to give feedback on 0.44 so we can fix really critical issues on the 0.45 branch.

This release should be scheduled just a few days after Rakudo is released.

Once it is done CSJewell creates the windows distributions based on Strawberry Perl.

That means we have these "packaged" and translated releases by ~ 20-25th of every month.