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.

Release of Padre

As of release 0.21 we started a rotation of release managers for Padre. See Release_History

• 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.
• cd to trunk/Padre
• Make sure the Changes file is up to date and manually update if necessary, add the vX.XX Date string at the top (commit)
• run perl ../tools/tidy_pm_files.pl that will apply blessed padre style in every module. (commit)
• run perl ../tools/update_version_number.pl VERSION that will update the version number in every module and report if there was no VERSION entry in a module. Those need to be fixed. (commit)
• run perl ../tools/release.pl --revision REV --version VERSION [--tag] will try to create a distribution using a temporary directory and copy the resulting Padre-X.XX.tar.gz in the current directory. The optional --tag flag will also create a tag in SVN. So the release manager first can run it dry and when she is sure it creates a good release can run it again to also tag it in SVN.
• Upload to ​http://perlide.org/download/source/ (needs to be done by Gabor)
• try installing it using pip, tell people on IRC #padre about it
• Upload to PAUSE
• Send announcement to ​padre-dev mailing list
• Send announcement to ​padre-news mailing list (Gabor might need to send the message but at leas he needs to approve it after you sent it)
• Submit announcement to ​http://use.perl.org/ or some other well-read blog (e.g. one that is syndicated on Iron Man and on ​http://blogs.padre.perlide.org/ )
• Update the Release History
• Add the version number to the list of versions in Trac (Gabor needs to do this)
• Important: Assign primary maintainer status to Gabor (PAUSE ID 'SZABGAB') for all namespaces that are new in the current release.
  • Log into your PAUSE account
  • Click "View Permissions" in the menu
  • Note all Padre::* classes for which you are listed as "first-come" (as opposed to "co-maint").
  • Click "Change Permissions" in the menu
  • Under "2. You are primary maintainer:" select any one or all of the Padre::* namespaces that appear in the list view.
  • Click Select for "2.1 Pass primary maintainership status to somebody else (giving it up at the same time)"
  • Make sure all Padre::* namespaces are selected in the new listbox.
  • Enter "SZABGAB" in the text field.
  • Click "Pass Maintainership Status".
  • You will automatically become co-maintainer instead of primary maintainer of the classes in question.
• ppm creation:
  • tar xzf Padre-X.XX.tar.gz
  • perl Makefile.PL
  • make
  • make ppm will create a Padre.ppd file and a Padre.tar.gz file
  • change the other files in /trunk/ppm according to the README there
  • upload Padre.tar.gz as Padre-X.XX.tar.gz to ​http://perlide.org/download/ppm/
  • upload the other files from trunk/ppm to ​http://perlide.org/download/ppm/
• Create executable for Linux:
  • make exe
  • Upload to ​http://perlide.org/download/binary/

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 can start releasing from a branch. Trying to capture the process here.

• A few (2 ?) days before the planned release date the release manager creates a copy:
• run perltidy on the trunk
• svn cp ​http://svn.perlide.org/padre/trunk/Padre ​http://svn.perlide.org/padre/branches/Padre-X.XX (replace X.XX with the future version number)
• Anyone who wants to work on the release branch can
• cd trunk/Padre
• svn switch ​http://svn.perlide.org/padre/branches/Padre-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
• do the regular release process as above
• when finished merge the branch back to trunk:
• svn switch ​http://svn.perlide.org/padre/trunk/Padre .
• svn log --stop-on-copy ​http://svn.perlide.org/padre/branches/Padre-X.XX
• Take the FIRST and LAST revision number from that log
• svn merge -rFIRST:LAST ​http://svn.perlide.org/padre/branches/Padre-X.XX/ .
• svn commit -m'merge -rFIRST:LAST ​http://svn.perlide.org/padre/branches/Padre-X.XX/'
• now you can remove the release branch:
• svn rm ​http://svn.perlide.org/padre/branches/Padre-X.XX/

Release of Plugins and other packages

The packages can use either Makefile.PL (Module::Install) or Build.PL (Module::Build). We have not tested the below process with ExtUtils::Makemaker

No need to keep MANIFEST and META.yml in version control!

Add to MANIFEST.SKIP

# avoid pot files (gettext)
\.pot$

If you are using Module::Build

Don't add a Makefile.PL to the version control as it will be created during packaging

Release process

• cd to the directory of the plugin or the package
• ../tools/
• run perl ../tools/tidy_pm_files.pl (commit)
• run perl ../tools/update_version_number.pl VERSION and update Changes (commit)
• run perl ../tools/release.pl REV VERSION [--tag]
• upload to PAUSE