Difference between revisions of "Release Checklist"
(DeSPAM) |
|||
| Line 21: | Line 21: | ||
3) Once you're actually ready for a release, '''make the tarball''', RIGS-x.y.z, and upload it to ftp.gnustep.org/pub/incoming. You can do this anonymously. | 3) Once you're actually ready for a release, '''make the tarball''', RIGS-x.y.z, and upload it to ftp.gnustep.org/pub/incoming. You can do this anonymously. | ||
| − | + | ||
| − | + | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
4) Once the file is uploaded, '''send an e-mail to webmasters@gnustep.org''', (which I am subscribed to, as well as others) and simply request that (A) the file be moved from the incoming directory on the FTP site to /pub/GNUstep/libs and (B) that we add a one-line news item to the GNUstep.org front page with a direct link to the latest tarball on the FTP site, and, OPTIONALLY, (C) add info to http://www.gnustep.org/experience/RIGS.html with what's new in the current version, etc. | 4) Once the file is uploaded, '''send an e-mail to webmasters@gnustep.org''', (which I am subscribed to, as well as others) and simply request that (A) the file be moved from the incoming directory on the FTP site to /pub/GNUstep/libs and (B) that we add a one-line news item to the GNUstep.org front page with a direct link to the latest tarball on the FTP site, and, OPTIONALLY, (C) add info to http://www.gnustep.org/experience/RIGS.html with what's new in the current version, etc. | ||
| Line 38: | Line 32: | ||
you can choose to just check out the main index.html page if you'd like. There are a couple of large (~17MB) files on the GNUstep.org website which might take a while to download depending on the speed of your Internet connection. | you can choose to just check out the main index.html page if you'd like. There are a couple of large (~17MB) files on the GNUstep.org website which might take a while to download depending on the speed of your Internet connection. | ||
| − | + | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Don't feel obligated to do step 6. It's actually not going to buy us much until we have a way set up where any gnustep person with CVS commit can post stuff anywhere on the GNUstep ftp site, but until then you will have to email webmasters@gnustep.org to ask us to move stuff from incoming/ to libs/ on the FTP site itself. We are of course more than happy to update the website for you, and since there are webmasters in both europe and the USA, it usually happens fairly quickly. If you do elect to update the website yourself, please be sure you know what you're doing. GNUstep.org pulls from CVS checkouts at the bottom of every hour, so be sure to check that the page updated properly the next time it goes live. In a worst-cast scenario, you might have bogus stuff on the main page for one hour. I do this accidentally from time to time. | Don't feel obligated to do step 6. It's actually not going to buy us much until we have a way set up where any gnustep person with CVS commit can post stuff anywhere on the GNUstep ftp site, but until then you will have to email webmasters@gnustep.org to ask us to move stuff from incoming/ to libs/ on the FTP site itself. We are of course more than happy to update the website for you, and since there are webmasters in both europe and the USA, it usually happens fairly quickly. If you do elect to update the website yourself, please be sure you know what you're doing. GNUstep.org pulls from CVS checkouts at the bottom of every hour, so be sure to check that the page updated properly the next time it goes live. In a worst-cast scenario, you might have bogus stuff on the main page for one hour. I do this accidentally from time to time. | ||
[[Category:Project procedures]] | [[Category:Project procedures]] | ||
Revision as of 13:01, 11 September 2005
This checklist details each step which needs to be taken in order to prepare a new version of apps and libs in the GNUstep repository for release.
Special thanks to Larry Coleman, who sent me an e-mail asking what the release criteria was, so he could do his first release of RIGS (he's the new maintainer). He gave me the final impetus to type up this document which I'd been intending to do for a long time.
Quick procedure
- Make sure it compiles against the latest releases of GNUstep-core, not just CVS
- Avoid version inconsistency - use single place for storing the version number and get it from there.
- Make the tarball with version number in the name ProjectName-1.0.0.tar.gz
- Send an e-mail to both: info-gnustep@gnu.org and gnustep-announce@gnu.org, optionaly you can send it to the gnustep-discuss@gnu.org
Detailed procedure
1) Make sure it compiles against the latest RELEASES of GNUstep-core, not just CVS...this is a common problem and it's simply embarassing. If it does not, delay the release until the next GNUstep release that includes the fixes you need. If it is critical that you release a new version, you can always appeal to the release manager for a new release via the gnustep-dev@gnu.org mailing list. You can build a separate $PREFIX/GNUstep-Release dir or something which you can then execute the GNUstep.sh file from this tree, which will make it use those release libs without trouncing on your current (perhaps CVS) GNUstep build.
2) Use single place for storing the version number and get it from there. Be it a header file, or defined macro in a makefile.
it's very embarressing when you forget to change it somewhere, as has recently happened with the ProjectCenter 0.4.2 release (which was still marked as 0.4.1 in numerous places, including the info panel and framework version :[ )
Original suggestion: grep for the version number in the source tree.... and change it everywhere...
3) Once you're actually ready for a release, make the tarball, RIGS-x.y.z, and upload it to ftp.gnustep.org/pub/incoming. You can do this anonymously.
4) Once the file is uploaded, send an e-mail to webmasters@gnustep.org, (which I am subscribed to, as well as others) and simply request that (A) the file be moved from the incoming directory on the FTP site to /pub/GNUstep/libs and (B) that we add a one-line news item to the GNUstep.org front page with a direct link to the latest tarball on the FTP site, and, OPTIONALLY, (C) add info to http://www.gnustep.org/experience/RIGS.html with what's new in the current version, etc.
5) Once the file has been moved to its permanent FTP directory (but you don't necessarily have to wait for the website to be updated to reflect this), send an e-mail to BOTH info-gnustep@gnu.org AND gnustep-announce@gnu.org with "ANN: RIGS version x.y.z etc et" in the subject, with a standard release-formatted e-mail (for a decent and recent ANN: example, see http://lists.gnu.org/archive/html/info-gnustep/2005-02/msg00000.html ) and be sure to include notable new changes. It's important to be informative about what has changed and why it's changed. Try to be as succinct as you can. (unlike /this/ e-mail ;-)
6) OPTIONAL: If you have CVS commit privelages to GNUstep, you also have the choice of updating GNUstep.org yourself via CVS. To check out the entire CVS GNUstep website, run:
CVS_RSH=ssh cvs -z3 -d <username>@savannah.gnu.org:/webcvs/gnustep co gnustep
you can choose to just check out the main index.html page if you'd like. There are a couple of large (~17MB) files on the GNUstep.org website which might take a while to download depending on the speed of your Internet connection.
Don't feel obligated to do step 6. It's actually not going to buy us much until we have a way set up where any gnustep person with CVS commit can post stuff anywhere on the GNUstep ftp site, but until then you will have to email webmasters@gnustep.org to ask us to move stuff from incoming/ to libs/ on the FTP site itself. We are of course more than happy to update the website for you, and since there are webmasters in both europe and the USA, it usually happens fairly quickly. If you do elect to update the website yourself, please be sure you know what you're doing. GNUstep.org pulls from CVS checkouts at the bottom of every hour, so be sure to check that the page updated properly the next time it goes live. In a worst-cast scenario, you might have bogus stuff on the main page for one hour. I do this accidentally from time to time.