hi again,

I forgot to mention... if these plans aren't suitable for any reason, please
let me know.

cheers!

On Tue, May 12, 2009 at 9:44 PM, René Dudfield <ren...@gmail.com> wrote:

> hello,
>
> I'm hoping we can release pygame1.9 in 3-4 weeks. Which means that there's
> about 1 week to get any last minute changes in. If they are new features, we
> will require docs/example, and tests... and it's probably too late to add
> any big features with an API larger than a function or two(unless the API
> has been discussed on the mailing list already).
>
> The pygame1.9release is timed this way, so that we can get a release out
> around the time the GSOC coding period officially starts. The GSOC students
> can be involved in a release, and we can devote more time to their new
> projects after the release is out(amongst other things). We should also have
> a good version ready for before python3.1 is released... whose release
> schedule <http://www.python.org/dev/peps/pep-0375/#release-schedule> says
> it is to be released in 6-7 weeks (June 27th).
>
> There are a number of things that need doing...
> - bugs that need attention(search the mailing list for BUG, or look at the
> bug tracker),
> - a whole bunch of unittests that could be written(all the functions that
> need tests are marked todo in the test/*.py files),
> - documentation fixes (from the doc comments).
> - the WHATSNEW file needs updating.  By looking at the svn commit logs and
> creating updating the file
> - making sure proper credit is given to people who've sent in patches...
> (in readme files etc)
>
>
> I'd like to finally finish off the pygame.midi stuff (docs and tests)...
> and after that start getting into the stuff above.
>
> As usual... we'll be using the release process from the file:
> docs/howto_release_pygame.txt
>
> I've pasted it in below.  We are at the first point "declare next release
> as coming soon to developers, and mailing list."
>
>
> If you'd like to test the latest pygame1.9 pre-release, please see:
> This page for windows and mac binaries:
> http://thorbrian.com/pygame/builds.php
>
> Or for compilation, follow these links:
> *Compilation <http://pygame.org/wiki/Compilation?parent=index>:* 
> Windows<http://pygame.org/wiki/CompileWindows?parent=index> MingW
> gcc on windows <http://pygame.org/wiki/MingW?parent=index> 
> MacOSX<http://pygame.org/wiki/MacCompile?parent=index>
> Ubuntu <http://pygame.org/wiki/CompileUbuntu?parent=index> 
> Suse<http://pygame.org/wiki/CompileSuse?parent=index> Red
> Hat <http://pygame.org/wiki/CompileRedHat?parent=index> Python 
> CE<http://pygame.org/wiki/CompilePythonCE?parent=index>
> Try and run your game with it, and report back any issues!
>
>
>
> cheers!
>
>
>
>
>
> == release steps ==
>
> *  declare next release as coming soon to developers, and mailing list.
> *  declare feature freeze.
> *  check with people on different platforms that tests are working.
> *  ask platform people to sign off for their platform building, and testing
> ok.
> *  WHATSNEW document is updated, with any changes.
> *  declare tar ball set, by making a branch in svn with the pygame version
> as rc1.  eg 1.7.1rc1
>    - files to change version string: lib/version.py setup.py readme.html
> readme.txt
>    - This is the subversion command used:  svn copy svn://
> seul.org/svn/pygame/trunk svn://seul.org/svn/pygame/tags/release_1_8_0rc1-m 
> "new 1.8.0rc1 release."
> *  second round of testing goes on the new release branch.  If any changes
> need to be made, all platforms need to be tested again and signed off.  The
> pygame rc version is incremented and a new rc tar ball is released.  eg
> 1.7.1rc2.
> *  if no changes needed to be made to the rc release, then the version is
> changed.  eg from 1.7.1rc1 to 1.7.1release
> *  release person uploads final sources tarball to website.
> *  documentation is remade, and uploaded to website, not before sources.
> *  release binaries, not before sources.
> *  announce to the mailing list, and the world that a new pygame is
> released.
> *  the version of pygame is incremented by 1 and pre appended.  eg 1.7.1
> goes to 1.7.2pre
>
>
>

Reply via email to