This is out of date in places. I haven't investigated which places. Note that there are multiple bug trackers, listed here in what mca considers the order of preference, http://sourceforge.net/tracker/?group_id=2653&atid=102653 http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Unit http://bugs.debian.org/libtest-unit-perl Also note use of ChangeLog instead of Changes, and parts of doc/TODO ------------------------------------------------- The procedure should be: ------------------------------------------------- Prerequisites: Make sure all the tests run OK. Make sure all the examples run OK. 1. Commit new files in src/Test-Unit 2. lib/Test/Unit.pm - put in the new $VERSION for the distribution 3. MANIFEST if files are to be added to the tarball ("make manifest" will add new files and tell you, but check they're not local cruft from your working copy. Get a clean checkout of the working copy to ensure no files are missing, or that you have removed deleted files from MANIFEST.) 4. cvs rtag -r HEAD REL_0_14 releasemodule (with the $VERSION number from above) 5. make clean ; perl Makefile.PL ; make tardist 6. upload to incoming as per Sourceforge docs 7. notify current CPAN maintainer to get an upload ------------------------------------------------- Explanation on version number synchronization: ------------------------------------------------- The CPAN module will decide to upgrade a module when the version number of the module installed locally is less than the highest version number of any version of the module it can find on CPAN. It will find out the distribution file this module is in, and then install this distribution file. This can lead to surprising results for distribution files that contain multiple modules. Take this common situation: package Foo-0.22.tar.gz contains modules Foo, Foo::Bar, and Foo::Baz. Now, something changes in Foo::Bar, and Foo::Bar gets a new version number. The module author happily uploads Foo-0.23.tar.gz to CPAN. Now, will the CPAN module use Foo-0.23.tar.gz to upgrade package Foo if you tell it "install Foo"? No. CPAN will look at the version number for Foo, determine it has not changed compared to the locally installed version, and do nothing. You have to tell it "install Foo::Bar" to get the new distribution file, which is bad, since nobody will know she has to do that. The solution is to make sure any time a distribution file gets upgraded, its top level module should get a new, higher version number. This way, things will work like people expect them to work. Please note that any module on CPAN should have a version number, even if it is contained in a package with many other modules. This ensures that people can require a certain version of any module in a given distribution file. ------------------------------------------------- References ------------------------------------------------- Date: Wed, 21 Feb 2001 14:06:35 +0000 From: Matthew Astley To: perlunit-devel@lists.sourceforge.net Subject: Re: [Perlunit-devel] CVS tags / release procedure Message-ID: <20010221140635.P25661@grantadesign.com> References: <20010220215614.H25661@grantadesign.com> <000901c09bf0$a1641140$9f0010ac@aixonix.de> <20010221130709.A9412@thelonious.new.ox.ac.uk> <20010220215614.H25661@grantadesign.com> <000901c09bf0$a1641140$9f0010ac@aixonix.de> In-Reply-To: <000901c09bf0$a1641140$9f0010ac@aixonix.de>; from lemburg@aixonix.de on Wed, Feb 21, 2001 at 11:25:36AM +0100 On Wed, Feb 21, 2001 at 11:25:36AM +0100, Christian Lemburg wrote: > OK so far, I suggest to replace the manual tar with > "make clean ; perl Makefile.PL ; make tardist" > (your perl will do the Right CPAN Thing for you). [revised] Commit new files in src/Test-Unit-0.1 including - Changes (section for release at the top) - Makefile.PL (set new $VERSION) - README (Version numbers on installation commands .. surely we could put something generic in here?) - MANIFEST if files are to be added to the tarball cvs rtag -r HEAD REL_0_14 releasemodule cvs exp -r REL_0_14 -d Test-Unit-n.nn src/Test-Unit-0.1 make clean ; perl Makefile.PL ; make tardist (upload to incoming as per Sourceforge docs) As for the CPAN stuff, is this complicated? Presumably the significant changes are documented in ExtUtils::MakeMaker? Also, since there's filtering via MANIFEST, is there any need to 'export' instead of running from a checked out working copy? Could Makefile.PL enquire of CVS or the top of the Changes file which version we're releasing? I'm thinking about reducing the number of things that need trivial tweaks before making a release. > > I'm left thinking that it could be handy to tag files as development > > only, so for example I could drop my GenericTests.pm into place but > > tag it as mine/not for release. It's rather hard for someone to commit > > on a patch, I think? So we've a solution to this separate problem, but perhaps we should hold off the feature creep until we've got more tests in? (any bright ideas for ways to tie the docs to the tests so the can fail a test when we tweak things? I'm just about to digress hugely so I'll save it for another post) > > * tag release stuff as STABLE or similar, then do > > > > cvs rtag -r STABLE REL_0_14 releasemodule [patches commands above, nb. "-r HEAD" instead of "-r STABLE"] > > > > and export that. > > That would be my preferred option. Would suit me too, since ATM we've no way to backtrace to a release. Only thing is, if you can release a checked out copy, the export is a little wasteful. Matthew #8-) From: "Christian Lemburg" To: "Matthew Astley" , References: <20010220215614.H25661@grantadesign.com> <000901c09bf0$a1641140$9f0010ac@aixonix.de> <20010221130709.A9412@thelonious.new.ox.ac.uk> <20010220215614.H25661@grantadesign.com> <000901c09bf0$a1641140$9f0010ac@aixonix.de> <20010221140635.P25661@grantadesign.com> Subject: Re: [Perlunit-devel] CVS tags / release procedure Date: Wed, 21 Feb 2001 15:58:34 +0100 > Also, since there's filtering via MANIFEST, is there any need to > 'export' instead of running from a checked out working copy? Could > Makefile.PL enquire of CVS or the top of the Changes file which > version we're releasing? No. You can just run from a checked out working copy. At least that was what I did until now. Cheers, Christian _______________________________________________ Perlunit-devel mailing list Perlunit-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/perlunit-devel