a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
Changes from previous:
0.55 (2010-03-27)
* Added a bunch of links to http://contributing.appspot.com/shipit
* Bunch of patches from the community all over the place... See
version control history, linked off the Contributing URL above.
(we should phase out this changelog, or make it just be the git
log....)
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
Collection.
Releasing a new version of software (Perl module) takes a lot of
steps... finding the next version number (and making sure you didn't
already use that version number before), making sure your changelog
is updated, making sure your "make dist" results in a tarball that
builds, commiting changes (with updated version number), tagging,
and uploading the tarball somewhere. Or maybe more steps. Or not
some of the above. Maybe you forgot something! And maybe you manage
multiple projects, and each project has a different release process.
You want to be hacking, not jumping through hoops. Your contributors
want to see their patches actually make it into a release, which
won't happen if you're afraid of releases. shipit automates all
the hell. It makes life beautiful.
