glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] Release process explained


From: nct
Subject: [glob2-devel] Release process explained
Date: Fri, 4 Aug 2006 11:27:26 +0200 (CEST)
User-agent: SquirrelMail/1.4.4

Hello,

In order to allow someone to take care of it, here is a detailed
description of the release process I've applied for all the alpha releases
:
0) Go into the directory containing glob2 HEAD
1) Check that the local cvs is up to date (through "cvs up")
2) Check that all the required graphics and maps are in the server
(through "./mkdata" and "./mkmaps")
3) Run "make dist-clean"
4) Increment version number in configure.in
5) Increment Debian version number by doing debchange -i in debian/
6) Set CXXFLAGS to "-O2 -g -march=i686", final release could be compiled
without the -g and with -O3 but right now -g -O2 is a reasonable tradeoff
between speed and debugability
7) Run "./bootstrap"
8) Run "./configure"; if any problem occurs, well, the HEAD is not ready
for release !
9) Run "make"; if any problem occurs, well, the HEAD is *still* not ready
for release !!
10) Run "make dist" to make the .tar.gz
11) Run "fakeroot debian/rules binary" to make the debian package
12) Upload them to
address@hidden:/home/glob2/public_html/releases/X.Y.Z (for
example, alpha20 = 0.8.20).
13) Send a mail to the ml, update web site, savannah news, and rest of the
Worlds about the "Good news" ;-)

Now some notes :
- The person taking care of release process should see with Kyle about ssh
key access for glob2 account.
- Right now, maps and data (music, graphics) are stored in the
globulation2 server, and uploaded through rsync over ssh. So any person
able to upload releases could also upload graphics. Problem is that rsync
is not a version control system and bad things can happen if two people
begin to manage those files in the same time. Unfortunately, cvs is very
bad at handling binary files. More unfortunately, savannah.gnu.org does
not provide svn (contrary to gna for instance). So we have the following
choices :
 * Keep the actual system and find one person responsible for binary data
 * Move binary files to cvs and be very carefull (but the probability to
have problem is huge)
 * Move from savannah to some place else (for instance gna) and migrate
cvs to svn (or to some other version control system). This takes time and
energy but is the most sustainable solution on the long term.

Any comment and help welcome, have a nice day,

Steph





reply via email to

[Prev in Thread] Current Thread [Next in Thread]