[GRASS5] Release Suggestion - HOWTO-RELEASE

[Frank Warmerdam]

On Sat, Jan 19, 2002 at 11:29:05PM +0100, Bernhard Reiter wrote:
> Markus raised the issue that it is about one working day for him 
> to release a grass version as tarball. This process has to be easier
> for him. Thus the following was suggested by Bernhard:
> 
> 	a) Markus will only release source tarball.

Markus, etc,

I can understand that producing a release can be a substantial amount of
work for something as large and complicated as GRASS.  I just wanted to
suggest one procedure that has helped me.  I now keep a HOWTO-RELEASE
file in each of my projects which lists the set of things I must do each
release.  

In theory this is mainly to make it easier for someone else to do a release
if I should be hit by a truck or something.  However, I also find I can
produce a source release substantially quicker with a detailed set of notes
on what needs to be done.  It also makes sure all the "release specific" 
information gets updated properly. 

I have attached my HOWTO-RELEASE from PROJ.4 as an example.  

I think it would be helpful to have something similar for GRASS. 

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent



	Preparing a PROJ.4 Release
	==========================


1) Update the version number in configure.in (in AM_INIT_AUTOMAKE()).

2) Update the version number in proj_api.h (#define PJ_VERSION).

3) Update the version number, and date in src/pj_release.c.

4) Update the version number in the -version-info definition in 
   src/Makefile.am.  It consists of "current:revision:age". 

   - If the library source code has changed at all since the last update, 
     then increment revision (c:r:a becomes c:r+1:a). 

   - If any interfaces have been added, removed, or changed since the last 
     update, increment current, and set revision to 0. 

   - If any interfaces have been added since the last public release, then 
     increment age. 

   - If any interfaces have been removed since the last public release, then 
     set age to 0. 

5) Add a note to the ChangeLog that a new release is being issued, and what
   the release number is.

6) Tag the release with a command like "cvs tag proj_4_4_3".

7) Do a "make dist-all" in the proj root directory.  After some grinding
   this should result in files like proj-4.4.3.tar.gz and proj-4.4.3.zip
   being created.  These are full source distributions. 

8) Put these in the proj ftp area on ftp.remotesensing.org.  This can be
   done via scp using a command like the following.

     scp proj-4.4.3.{tar.gz,zip} remotesensing.org:/ftp/remotesensing/pub/proj

9) Update html/index.html to link to the new release tar/zip files.  When
   committed this updates the web page on remotesensing.org.

10) Announce the new release on the PROJ.4 mailing lists.  If the release
   is particularly significant in terms of features it might also be 
   announced in comp.infosystems.gis, os-remotesensing at remotesensing.org, 
   and freegis-list at intevation.de.  

11) Issue a new release report on Freshmeat.  

   http://freshmeat.net/projects/proj.4/



NOTES:

 o Information about preparing binary releases, and RPMs should be formalized.
 o A "beta" release step should likely be incorporated.