wiki:Release

Version 16 (modified by waxhead, 4 years ago) (diff)

--

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. As of August 2009 we started a monthly rotation of release managers. See schedule below. 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. Make sure you get Wx::Perl::Dialog, Wx::Perl::Dialog::Frame, Wx::Perl::Dialog::Simple, and Wx::Perl::Dialog::SingleChoice? too.
  • 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_project.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)
  • 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.
    • Upload it somewhere public and ask Gabor to copy to http://perlide.org/download/source/
    • Tell people on IRC #padre about it and ask them to test 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. A trac admin needs to do this:
    • Go to Admin/Versions? in the "Name:" box type in the version number eg. 0.45, click on "Add"
    • Select the radio box on the right hand side of the newly added line and click on "Apply changes"
  • 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:
  • Create executable for Linux:

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.

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_project.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

Release Manager

The current release manager is Ryan52 starting from 0.46 (Sept 2009) for about one month

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.

See this post http://mail.perlide.org/pipermail/padre-dev/2009-August/001203.html and create a better tuned process for the "packaged" releases.