Next | Query returned 23 messages, browsing 21 to 30 | previous

History of commit frequency

CVS Commit History:


   2010-08-21 18:37:14 by Stoned Elipot | Files touched by this commit (1724) | Package updated
Log message:
Bump the PKGREVISION for all packages which depend directly on perl,
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!
   2010-03-17 00:05:01 by Jens Rehsack | Files touched by this commit (2)
Log message:
Updating devel/p5-ShipIt from 0.52 to 0.53

pkgsrc changes:
- Add license definition

Upstream changes:
0.53 (2009-12-15)
	* Mercurial support
	* Module::Build support
   2008-10-22 20:40:54 by Stoned Elipot | Files touched by this commit (3) | Imported package
Log message:
Initial import of p5-ShipIt version 0.52 in the NetBSD Packages
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.


Next | Query returned 23 messages, browsing 21 to 30 | previous