source: project/wiki/releasing-your-egg @ 39085

Last change on this file since 39085 was 39085, checked in by Mario Domenech Goulart, 3 months ago

releasing-your-egg: add note on `release' forms not being supposed to be removed from .release-info files

File size: 26.2 KB
Line 
1== Releasing your egg
2
3[[toc:]]
4
5Let's say you've been reading the [[eggs tutorial]] and you are almost
6done writing your first egg.  You've tested that it works locally, and
7now you probably want to make it available to others.  If you would
8like people to be able to install your egg using {{chicken-install YOUR-EGG}},
9there are a few steps you need to take.
10
11=== Note for Subversion users
12
13Before going on details on the process for Subversion,
14please note that hosting '''new''' eggs in the '''CHICKEN central
15Subversion repository''' is '''deprecated'''.  We recommend using
16your own code server or one of the hosts available on the Internet
17(e.g., github, bitbucket etc.).
18
19If you host your egg on {{code.call-cc.org}} or you host your own,
20you don't ''have'' to do any of the steps below.  Instead, you can
21use the release generating script at call-cc.org.  It does all the
22steps below automatically.
23
24The URI for an automatically generated release-info for egg YOUR-EGG is
25{{http://code.call-cc.org/release-info?egg=YOUR-EGG}}
26
27This URI can be put in the {{egg-locations}} file as described under
28[[#publishing-your-egg|"Publishing your egg"]].
29
30If you want more control over the process, please read on.
31
32=== Creating a release-info file
33
34First, you must create a so-called "release-info" file and make it
35available on a well-known location via HTTP (discussed below).  This
36is a file which describes where the released versions of your egg can
37be found.
38
39After everything's set up, releasing a new version of your egg is
40simply a matter of tagging your release with your VCS of choice and
41adding a line to this file. See [[#helper-scripts|below]] for some tools
42to automate even this small step.
43
44It looks something like this:
45
46<enscript highlight="scheme">
47(repo git "git://example.com/{egg-name}.git")   ; optional
48
49(uri targz "http://example.com/{egg-name}/releases/{chicken-release}/{egg-name}-{egg-release}.tar.gz")
50(release "0.1")
51(release "0.2")
52(release "1.0")
53</enscript>
54
55This example describes where to find the canonical repository and an URI pattern
56which describes how to find release tarballs.  It then goes on to declare three
57official releases; 0.1, 0.2 and 1.0.  Please note that releases are not supposed
58to be removed from the .release-info file, as it would cause consistency issues
59in case we want to rebuild caches.
60
61The patterns in the URI enclosed in curly braces are seen as
62substitution patterns to be replaced by values.  {{egg-name}} expands
63to the current egg's name (which is already known when the
64release-info file is being fetched), {{egg-release}} is replaced by
65the string in each {{release}} declaration.  {{chicken-release}} is
66replaced by the major CHICKEN version for which the egg is being
67fetched.  This allows you to supply different packages for each major
68CHICKEN release.
69
70The supported types for {{uri}} are currently {{targz}}, {{tarbz2}}, {{zip}},
71{{meta-file}} and {{files-list}}.  The first three are all archives expected
72to extract to a directory with the egg sources in it (zip files are allowed
73to expand directly into the files, but this is not recommended).  The latter
74two are special and deserves some more explanation; see the next section for that.
75
76Currently {{repo}} is not used by automated tools, but is intended to
77make it easy for users to find the repository.  In preparation for
78when it will be used in the future, it's a good idea to use consistent
79names, so please use the ''short name'' of the tool.  Generally this is
80how it is invoked on the commandline: {{git}}, {{hg}}, {{svn}}, {{fossil}}, {{bzr}}, {{mtn}}, {{darcs}} etc.
81
82==== Meta-file distribution
83
84Sometimes it is impractical to create archives containing your egg's file
85contents.  The egg releasing system has been designed to require as few manual
86steps as possible, so it is easy for people to release early and often.
87
88A core ideal of the release system is to make it possible to release
89simply by tagging your code in a VCS.  Some code hosting sites
90automatically make archives available for each tagged version, thereby
91making the release available immediately when the code is pushed to
92the server.  For those that don't, the meta-file distribution file
93type is a way to release by tagging ''without'' having to manually
94make a tarball, ''as long as there is a way to directly obtain the raw
95sources of a specific release version via HTTP''.
96
97The idea is that each released egg always must have a meta-file to describe
98its dependencies, its author and license and so on.  This meta-file can be
99used to provide a listing of all the files that are part of an egg.  The system
100that manages egg releases automatically will download all these files and put
101them in a directory.  When someone requests your egg with {{chicken-install}},
102these files are all served up.  Just add a {{files}} entry to your meta-file,
103which lists the files (these are resolved relatively to the meta-file itself).
104
105<enscript highlight="scheme">
106((files "uri-common.setup" "uri-common.release-info" "uri-common.meta"
107        "uri-common.scm" "tests/run.scm")
108 (license "BSD")
109 (category web)
110 (depends (uri-generic 2.3) defstruct matchable)
111 (test-depends test)
112 (author "Peter Bex")
113 (synopsis "Parser for common URI schemes"))
114</enscript>
115
116This is a real-world example of the [[/eggref/4/uri-common|uri-common egg]].
117It lists all the files which it consists of, and these will be downloaded by
118chicken-install.  The disadvantage of this approach is that if you forget a
119file, your egg is uninstallable, so if you can please use the archive
120distribution types instead.  Another disadvantage is that every time you add,
121remove or rename a file you need to remember to change the meta-file.
122
123The {{uri}} entry in uri-common's {{release-info}} file looked like this
124before there was an autogenerated one:
125
126<enscript highlight="scheme">
127(uri meta-file "http://anonymous@code.call-cc.org/svn/chicken-eggs/release/{chicken-release}/{egg-name}/tags/{egg-release}/{egg-name}.meta")
128</enscript>
129
130Because this egg uses subversion and each release has a corresponding
131tag, it can simply point to the metafile in the right subdirectory
132under tags and it will simply work.  For other version systems this
133may require some more messing around.
134
135==== files-list
136
137This is an extremely stupid format containing a manifest of files in
138an egg.  It's mostly useful when automatically generating lists of files.
139It starts with a base URI and then lists all the files in the egg.
140Here's the [[http://code.call-cc.org/files-list?egg=uri-generic;egg-release=1.0;chicken-release=4|files-list for version 1.0 of the uri-generic egg for CHICKEN 4]]:
141
142  http://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/uri-generic/tags/1.0
143  tests/run.scm
144  uri-generic.meta
145  uri-generic.scm
146  uri-generic.setup
147
148The trailing slash after the URI is required.
149
150It's not recommended you use this manually, as this format is subject
151to change and only really intended to be used as a communication system
152between [[/eggref/4/pseudo-meta-egg-info|pseudo-meta-egg-info]] and
153[[/eggref/4/henrietta-cache|henrietta-cache]].
154
155However, if you really need to use this, you can replace the
156{{meta-file}} uri type in the example above by {{files-list}}, like
157the auto-generated
158[[http://code.call-cc.org/release-info?egg=uri-generic|release-info file for uri-generic]],
159which starts like this:
160
161  (uri files-list "http://code.call-cc.org/files-list?egg={egg-name};egg-release={egg-release};chicken-release={chicken-release}")
162  (release "1.0")
163  (release "1.1")
164
165=== Publishing your egg
166
167After creating the release-info file, you need to make it known to the
168chicken-install infrastructure that an egg with the given name has a
169release info file at the location where you published it.  This step finally
170makes it possible for people to say {{chicken-install YOUR-EGG}} and have
171it install your egg, or use {{(depends YOUR-EGG)}} in meta-files of their eggs.
172
173Currently this is done by adding a line to the egg-locations file in
174Subversion, which can be found at
175[[https://code.call-cc.org/svn/chicken-eggs/release/4/egg-locations]]. For security reasons, editing the {{egg-locations}} file requires special permissions.  So, to have an entry for your egg in that file, send a message to the [[http://lists.nongnu.org/mailman/listinfo/chicken-users|chicken-users mailing list]] announcing your egg and requesting the inclusion of its location to {{egg-locations}}.
176
177To keep maintenance to a minimum, it's best to add a release-info
178location which will never change; only the release-info file itself
179should be changed when you make a new release.  This can most easily
180be accomplished by pointing to the "raw file" view of your
181trunk/tip/head/master branch in your canonical repository's web
182interface.  That way, this file is kept under version control
183alongside all the other files in your egg.
184
185If you do have an svn account and don't want to checkout the whole egg
186repository to be able to just edit this file, you can work around svn's
187limitations like this:
188
189 $ cd /tmp
190 $ svn co https://code.call-cc.org/svn/chicken-eggs/release/4 --depth empty
191 $ cd 4
192 $ svn update egg-locations
193
194If you prefer, you can just publish the file separately via HTTP
195somewhere and keep overwriting it.  If your code hoster doesn't
196provide an easy way to point to a raw view on a moving "latest
197version" pointer via HTTP, you could instead opt to store just the
198release-info files of your eggs in the centralised CHICKEN eggs
199subversion repository.  Just contact one of the project maintainers or
200write to the chicken-users mailinglist.
201
202=== Instructions for popular code hosting methods and VCSes
203
204Now we've explained the basic idea, here's an overview of how to figure
205out the correct URIs and how to automate some steps away.
206
207==== Bitbucket (mercurial, git)
208
209===== Location of release-info file
210
211You can use the code browser to figure out the path to your
212release-info file.  First, copy the link that says "raw".  This URI is
213almost correct but will contain a revision ID hash, so it is pinned to
214whatever revision is currently the tip.  However, you can replace it
215with the string "tip" and it will still work, and when you visit it again
216after making changes it will have picked up those changes.  Example:
217
218Clicking "mini-kanren.release-info" and then copying the "raw" link on
219[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/src]] gives us
220[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/raw/8af0b51f5efac79c8bc0cfe856185ad06d7aa9d0/mini-kanren.release-info]]
221
222Just change it to
223[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/raw/master/mini-kanren.release-info]]
224and you have the latest master version.  If you're using Mercurial
225instead of git, use {{tip}} instead of {{master}}.
226
227This link should be registered in the egg-locations list for your egg
228and it will automatically be able to fetch any new releases as they
229are tagged and added to the release-info file.
230
231===== Making releases
232
233The bitbucket code browser also offers a "get source" link that allows
234you to fetch the files in that revision as a tarball.  The same trick
235as with the raw files works here; just replace the link's revision ID
236hash with a symbolic name.  You can use tags and bookmarks as symbolic
237names.
238
239So to make a new release, just tag your release with a well-defined
240name. If you tag your eggs with the version as tag or bookmark name,
241you can use the following release-info file.  Just don't forget to
242substitute your bitbucket username!
243
244<enscript highlight="scheme">
245(repo hg "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}")
246(uri targz "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}/get/{egg-release}.tar.gz")
247(release "0.1")
248</enscript>
249
250==== GitLab (git)
251
252===== Location of release-info file
253
254Use the code browser ("Files" in the menu) to browse to your master
255branch's release-info file and copy the "Raw" link.  For example, for
256the [[/eggref/4/sdl2|SDL2 egg]] it looks like this:
257
258[[https://gitlab.com/chicken-sdl2/chicken-sdl2/raw/master/sdl2.release-info]]
259
260===== Making releases
261
262GitLab makes tags available for download as tarballs.  To find the
263location, go to the code browser and switch to a tag at the top left.
264On the right side there's a drop-down menu that offers a download for
265various archive formats.
266
267So to make a new release, just tag your release with a well-defined
268name. If you're using gitlab.com's hosted service and tag your eggs
269with the version as tag name, you can use the following release-info
270file.  Just don't forget to substitute your GitLab project name!
271
272<enscript highlight="scheme">
273(repo git "https://gitlab.com/PROJECT-NAME/{egg-name}.git")
274(uri targz "https://gitlab.com/PROJECT-NAME/{egg-name}/repository/archive.tar.gz?ref={egg-release}")
275(release "0.1")
276</enscript>
277
278
279==== GitHub (git)
280
281===== Location of release-info file
282
283Use the code browser ("source" tab) to browse to your release-info
284file and copy the "raw" link.  This link should work as-is, as long as
285you do this while looking at the latest revision of the file in the
286master branch.  For example, for the [[/eggref/4/kalaha|Kalaha egg]]
287it would look like:
288
289[[https://raw.github.com/DerGuteMoritz/kalaha/master/kalaha.release-info]]
290
291===== Making releases
292
293GitHub makes tags available for download as tarballs.  To find the
294location, click the big "Downloads" button/link in the code browser.
295It will pop up a selection dialog where you can choose between tarball
296and "zipball".  It will also offer downloads for each tag, but those
297are zipballs only.  However, you can copy the link and replace
298"zipball" in the URL by "tarball", or you can first click "switch
299tags" and then open the "Downloads" dialog and it will offer you
300download links for both tar and zip for that specific tag.
301
302So to make a new release, just tag your release with a well-defined
303name. If you tag your eggs with the version as tag name, you can use
304the following release-info file.  Just don't forget to substitute your
305GitHub username!
306
307<enscript highlight="scheme">
308(repo git "git://github.com/YOUR-GITHUB-USERNAME/{egg-name}.git")
309(uri targz "https://codeload.github.com/YOUR-GITHUB-USERNAME/{egg-name}/tar.gz/{egg-release}")
310(release "0.1")
311</enscript>
312
313
314==== Gitweb (git)
315
316===== Location of release-info file
317
318Navigate to the "tree" view for the master branch of your project and
319copy the "raw" link for your release-info file. The link will look
320something like this, for an egg "foo":
321
322 http://gitweb/gitweb.cgi?p=foo.git;a=blob_plain;f=foo.release-info
323
324===== Making releases
325
326The download link for a tarball of a specific Git tag is accessible
327through Gitweb with a query string like the following:
328
329 http://gitweb/gitweb.cgi?p={egg-name}.git;a=snapshot;h=refs/tags/{egg-release};sf=tgz
330
331So, if you tag each release and use a release-info file like the
332following, every new tag will be made available as a tarball at that URL
333(make sure to substitute your Git URL and Gitweb host into {{repo}}
334and {{uri}} strings):
335
336<enscript highlight="scheme">
337(repo git "git://gitweb/{egg-name}.git")
338(uri targz "http://gitweb/gitweb.cgi?p={egg-name}.git;a=snapshot;h=refs/tags/{egg-release};sf=tgz")
339(release "0.1")
340</enscript>
341
342
343==== Sourcehut (mercurial, git)
344
345===== Location of release-info file
346
347For a Git repository, navigate to the "tree" view for the master branch
348of your project, select your release-info file and copy the "View raw"
349link from that page. The URL will look something like this, for user
350"user" and egg "example":
351
352 https://git.sr.ht/~user/example/blob/master/release-info
353
354For a Mercurial repository, go to your project's "browse" tab, select
355your release-info file and copy the "View raw" link. The URL should look
356like this:
357
358 https://hg.sr.ht/~user/example/raw/release-info
359
360===== Making releases
361
362Sourcehut provides download URLs for tags in both Mercurial and Git
363repositories. So, in either case you can make a new release by simply
364tagging your egg.
365
366If you use version numbers as tag names, you can use the following
367release-info files, replacing "USERNAME" with your own. Note the leading
368tilde, which must be included!
369
370For Git:
371
372<enscript highlight="scheme">
373(repo git "https://git.sr.ht/~USERNAME/{egg-name}")
374(uri targz "https://git.sr.ht/~USERNAME/{egg-name}/archive/{egg-release}.tar.gz")
375(release "0.1")
376</enscript>
377
378For Mercurial:
379
380<enscript highlight="scheme">
381(repo git "https://hg.sr.ht/~USERNAME/{egg-name}")
382(uri targz "https://hg.sr.ht/~USERNAME/{egg-name}/archive/{egg-release}.tar.gz")
383(release "0.1")
384</enscript>
385
386
387==== Cgit (git)
388
389===== Location of release-info file
390
391Navigate to the "tree" view for the master branch of your project and
392copy the "plain" link for your release-info file (it's all the way to
393the right). The link will look something like this, for an egg "foo":
394
395 http://cgit.example.com/foo/plain/foo.release-info
396
397For example, the release info for the [[/eggref/4/hardwood|Hardwood
398egg]] looks like this:
399
400[[http://www.upyum.com/cgit.cgi/hardwood/plain/hardwood.release-info]]
401
402The {{cgit.cgi}} part is optional, depending on how cgit was
403configured.  For example, the release-info for the
404[[/eggref/4/scsh-process|scsh-process egg]] looks like this:
405
406[[http://code.more-magic.net/scsh-process/plain/scsh-process.release-info]]
407
408===== Making releases
409
410The download link for a tarball of a specific Git tag can be found by
411visiting "refs", then the tag, following it to the commit and if
412snapshots are shown there should be a download link, but it links
413directly to the commit hash.  You can simply replace the hash with the
414symbolic tag name.
415
416If snapshots are not shown, it's still possible to construct the link
417manually, and it will work:
418
419 http://cgit.example.com/cgit.cgi/{egg-name}/snapshot/{egg-name}-{egg-release}.tar.gz
420
421So, if you tag each release and use a release-info file like the
422following, every new tag will be made available as a tarball at that
423URL (make sure to substitute your Git URL and Cgit host into
424{{repo}} and {{uri}} strings):
425
426<enscript highlight="scheme">
427(repo git "http://cgit.example.com/cgit.cgi/{egg-name}")
428(uri targz "http://cgit.example.com/{egg-name}/snapshot/{egg-name}-{egg-release}.tar.gz")
429(release "0.1")
430</enscript>
431
432==== hgweb (mercurial) - aka "hg serve"
433
434The built-in web interface for mercurial can be used to serve up eggs,
435usually invoked from hgweb and hgwebdir on a "real" server.
436
437===== Location of release-info file
438
439Use the browser to navigate to the latest revision of the release-info
440file and click the "raw" link on the left.  Then replace the commit ID
441hash with "tip".  Example:
442
443[[http://example.com/my-egg/raw-file/tip/my-egg.release-info]]
444
445===== Making releases
446
447Since this interface doesn't have a way to serve up tarballs, you must
448either create your own tarballs and publish them elsewhere or use the
449manual "meta-file" way.
450
451See [[#meta-file-distribution|the meta-file section]] at the start of
452this wiki page to figure out how to set up a {{files}} section in your
453meta-file.  The URI to your meta file is similar to the release-info
454file, except this time you can replace "tip" with the release's
455tagname.  If you use tagnames that are identical to the release
456version, you can base the release-info file on the following example:
457
458<enscript highlight="scheme">
459(repo hg "http://example.com/{egg-name}")
460(uri meta-file "http://example.com/{egg-name}/raw-file/{egg-release}/{egg-name}.meta")
461(release "0.1")
462</enscript>
463
464This assumes hgwebdir is running on the domain's root URI and the egg
465is available in a repo which has the same name as your egg.
466
467==== Fossil's default web UI
468
469This is the web UI you get when running "fossil serve" or when running
470fossil as a CGI script.
471
472There is one tricky part: by default, this interface disallows almost
473all outside access; you ''must'' log in, even if you just want to
474browse anonymously. To allow everybody to download release zipfiles or
475tarballs without login, add the "z" permission for the user "nobody"
476in the Admin / Users section of the web UI or with the "fossil user
477capabilities" command.
478
479===== Location of release-info file
480
481Fossil's web UI allows serving of documents directly from the
482repository under URLs of the form
483"http://example.com/my-egg/doc/{version}/{file}". If the files have a
484".txt" or ".wiki" extension, they are rendered into HTML, but anything
485else is served as is.
486
487For example you can store the release-info file in the repository and
488always access the latest version of the default branch at a URL like
489"http://example.com/my-egg/doc/trunk/my-egg.release-info".
490
491===== Making releases
492
493Fossil can serve tarballs or zipfiles of repository snapshots. A
494release-info file using zipfile packaging may look like this:
495
496<enscript highlight="scheme">
497(repo fossil "http://example.com/{egg-name}")
498(uri zip "http://example.com/{egg-name}/zip/{egg-name}.zip?uuid=v{egg-release}")
499(release "1.0.0")
500</enscript>
501
502For tarball packaging, the equivalent {{uri}} entry should look like
503this:
504
505<enscript highlight="scheme">
506(uri targz "http://example.com/{egg-name}/tarball/{egg-name}.tar.gz?uuid=v{egg-release}")
507</enscript>
508
509The releases are referenced using symbolic tags of the form
510"v{egg-release}" here. You can add these tags to the changesets
511corresponding to released versions of the egg using the "fossil tag
512add" command.
513
514==== Launchpad (bazaar)
515
516Unfortunately, Launchpad doesn't currently seem very suitable for
517developing eggs in a streamlined way.  Here's a description of one
518possible way to integrate with their way of doing release management though.
519
520===== Location of release-info file
521
522You can browse to the release-info file using Loggerhead (the web
523interface to bazaar), but there doesn't seem to be a reliable way to
524construct a raw download URI for "the latest version of" a file.
525
526A workaround is to create a release series just for the release-info,
527and make an (unused) milestone for that.  Then you can upload a
528release-info file.  The URI that's listed directly on the downloads
529page is stable though (something like
530[[http://launchpad.net/my-project/main/release-info/+download/my-egg.release-info]]
531if you named the milestone "release-info" in the "main" series)
532This link redirects to an unstable URI, so don't paste that one!
533
534When you make a new release you can ''delete'' the file and upload a new
535one manually to the same pseudo-"release".
536
537
538===== Making releases
539
540If you do it through their release management, you just create release
541tarballs which you manually upload into the release milestone.
542
543The only automation here is that you can use {{bzr export --format=tgz}}
544to create it, and the advantage that you're using someone else's site to
545host your code.
546
547You can use this release-info file template if you are consistent in
548your milestone naming.  It assumes you used the name "main" for the
549series from which releases for chicken-install are made.  You could
550alternatively add several {{uri}} entries, one per series, but it's
551still required that your egg's release versions are unique for your
552egg.  Series are probably more suitable for distinguishing between
553major CHICKEN release versions.
554
555<enscript highlight="scheme">
556(repo bzr "lp:MY-PROJECT/main")
557
558(uri targz "http://launchpad.net/MY-PROJECT/main/{egg-release}/+download/{egg-name}.tar.gz")
559(release "0.1")
560(release "0.2")
561</enscript>
562
563
564=== Helper scripts
565
566To make life easier, there are some helper scripts, hooks etcetera
567that could be used.  Please add your own links here.
568
569==== Subversion
570
571There's an [[/eggref/4/svn-egg-author|svn-egg-author egg]] that helps
572you to update the release-info and meta files and tag a release of
573your egg, all with one command.
574
575If you run your own subversion server with Spiffy, you can consider
576using [[/eggref/4/pseudo-meta-egg-info|pseudo-meta-egg-info]] instead.
577If you do, you do not need to use svn-egg-author.  If you're using the
578chicken-eggs repository hosted on call-cc.org, you don't need it either
579because call-cc is already running pseudo-meta-egg-info for all its eggs.
580
581==== Mercurial
582
583There's an
584[[http://code.more-magic.net/hg-egg-author/plain/egg-author.py|egg-author]]
585extension for Mercurial that allows you to say {{hg eggtag 0.1}} and have it
586automatically update the release-info file with the new tag name.
587
588==== Git
589
590There's a [[/eggref/4/git-egg-author|git-egg-author egg]] that helps you
591keep your release-info file up-to-date and tag a release with one command.
592
593==== Bazaar
594
595There's also a [[https://launchpad.net/bzr-egg-author|bzr-egg-author]]
596extension for Bazaar that allows you to say {{bzr eggtag 0.1}} and have it
597automatically update the release-info file with the new tag name.
598
599=== Moving an egg
600
601When you decide to migrate to a different code hosting site, and don't
602want to move all releases, you can define multiple uris:
603
604<enscript highlight="scheme">
605;; Main ("default") repo
606(repo hg "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}")
607(uri targz "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}/get/{egg-release}.tar.gz")
608(release "2.1")
609(release "2.0")
610
611;; Old repo, using "old-svn-repo" alias
612(repo svn "http://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/{egg-name}")
613(uri files-list "http://code.call-cc.org/files-list?egg={egg-name};egg-release={egg-release};chicken-release={chicken-release}" old-svn-repo)
614(release "1.3" old-svn-repo)
615(release "1.2" old-svn-repo)
616(release "1.1" old-svn-repo)
617(release "1.0" old-svn-repo)
618(release "0.2" old-svn-repo)
619(release "0.1" old-svn-repo)
620</enscript>
621
622
623=== Testing new eggs before publishing them
624
625The initial setup of a new egg is relatively tricky.  Some details have to be
626properly configured before the official release.  For example:
627
628* The .release-info file must be publicly available, so that [[/egg/henrietta-cache|henrietta-cache]] can access it.
629* The syntax of the .release-info file must be correct, and the releases and tarballs it points to must be consistent.
630* The egg code must be compilable and installable.  Usually you test it from the local source code repository, which can be in a different state from the remote source repository -- that leads to problems when making the egg available.
631* The egg metadata must be properly specified (e.g., dependencies) -- that's another thing that can cause problems if the egg is tested with the CHICKEN installation that is used for development (on which environment the dependencies are already installed, thus missing specification of dependencies go unnoticed).
632
633Manually testing all these aspects can be boring and prone to mistakes.  To make the life of egg authors easier, we have a tool to test initial versions of eggs: [[/egg/test-new-egg|test-new-egg]].  Using it is very easy: just install it (via chicken-install) and provide the URI for the .release-info file as argument to it:
634
635  $ test-new-egg <egg name> <.release-info file's URI>
636
Note: See TracBrowser for help on using the repository browser.