1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
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 <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
|
