-------------------------------------------------
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
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 lemburg@acm.org for upload to CPAN

Cheers,

Christian Lemburg

-------------------------------------------------
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 <mca-gdl@users.sourceforge.net>
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. <shrug>


Matthew  #8-)


From: "Christian Lemburg" <lemburg@aixonix.de>
To: "Matthew Astley" <mca-gdl@users.sourceforge.net>,
        <perlunit-devel@lists.sourceforge.net>
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

