I thought may be putting together a release schedule would help making 3.2
closer to reality.

I would really like to see it out some time before the next ApacheCon US
(10-14 December). I've submitted a mod_python talk and if it gets
approved, it'd be nice to be able to discuss the new/fixed things in 3.2.

Just to remind everyone how a release works - first a tar file is
produced, which is announced only on the list. A few people on the list (3
or more preferabley) need to test it and send in their +1's (or -1's). If
all is well, the file is released to the public, else we repeat this
cycle.

I think that 3.2 should initially be relased as 3.2.0 beta, with a plan to
release 3.2.X as stable a few weeks later.

Assuming that the release iteration will take 3 weeks (this is a worst
case scenario),

Aug 15		3.2.0b 	private release
Sep 7		3.2.Xb	approved for public release

Nov 7		3.2.Y	private release
Nov 15		3.2.Y	public release

[I'm using X and Y since we don't know what those numbers may be]

The Sep 7 - Nov 7 is a month for public testing of 3.2.Xb.

Does this sound like a plan?

Jim - do you think you'll be able to make a unix .tgz by Aug 15?

Anyone would like to volunteer to make a win32 version?

Grisha

[ Post a follow-up to this message ]

Hi Grisha,

What do you want for the win32 version ? I regularly rebuild the win32 
installer from the latest Subversion revision and put it there : 
http://nicolas.lehuen.com/download/mod_python . Using this installer, people
 
can test and give their +1 / -1. Is that OK for you ?

Regards,
Nicolas

2005/8/8, Gregory (Grisha) Trubetskoy <grisha@ispol.com>:
> 
> 
> I thought may be putting together a release schedule would help making 3.2
> closer to reality.
> 
> I would really like to see it out some time before the next ApacheCon US
> (10-14 December). I've submitted a mod_python talk and if it gets
> approved, it'd be nice to be able to discuss the new/fixed things in 3.2.
> 
> Just to remind everyone how a release works - first a tar file is
> produced, which is announced only on the list. A few people on the list (3
> or more preferabley) need to test it and send in their +1's (or -1's). If
> all is well, the file is released to the public, else we repeat this
> cycle.
> 
> I think that 3.2 should initially be relased as 3.2.0 beta, with a plan to
> release 3.2.X as stable a few weeks later.
> 
> Assuming that the release iteration will take 3 weeks (this is a worst
> case scenario),
> 
> Aug 15 3.2.0b private release
> Sep 7 3.2.Xb approved for public release
> 
> Nov 7 3.2.Y private release
> Nov 15 3.2.Y public release
> 
> [I'm using X and Y since we don't know what those numbers may be]
> 
> The Sep 7 - Nov 7 is a month for public testing of 3.2.Xb.
> 
> Does this sound like a plan?
> 
> Jim - do you think you'll be able to make a unix .tgz by Aug 15?
> 
> Anyone would like to volunteer to make a win32 version?
> 
> Grisha
>

[ Post a follow-up to this message ]

Gregory (Grisha) Trubetskoy wrote:
>
> I thought may be putting together a release schedule would help making
> 3.2 closer to reality.
>
> I would really like to see it out some time before the next ApacheCon US
> (10-14 December). I've submitted a mod_python talk and if it gets
> approved, it'd be nice to be able to discuss the new/fixed things in 3.2.
>
> Just to remind everyone how a release works - first a tar file is
> produced, which is announced only on the list. A few people on the list
> (3 or more preferabley) need to test it and send in their +1's (or
> -1's). If all is well, the file is released to the public, else we
> repeat this cycle.
>
> I think that 3.2 should initially be relased as 3.2.0 beta, with a plan
> to release 3.2.X as stable a few weeks later.

Make sense to me.

> Assuming that the release iteration will take 3 weeks (this is a worst
> case scenario),
>
> Aug 15        3.2.0b     private release
> Sep 7        3.2.Xb    approved for public release
>
> Nov 7        3.2.Y    private release
> Nov 15        3.2.Y    public release
>
> [I'm using X and Y since we don't know what those numbers may be]
>
> The Sep 7 - Nov 7 is a month for public testing of 3.2.Xb.
>
> Does this sound like a plan?

This schedule looks good to me. I've been putting the finishing touches
on the docs for FileSession. (And making a couple of changes to
Session.py so that the code matches the docs ;) ). Should be done in 30
minutes.

> Jim - do you think you'll be able to make a unix .tgz by Aug 15?
>

Making the tarball takes about 5 minutes, so yes, that would be fine.

A little off topic, but I was testing my documentation changes yesterday
and I noticed that the version was not getting changed in the generated
files. I had to make a small change in the sed script which does the
search and replace in modpython.tex. GNU sed was not escaping the
\\release properly; it was looking for a CR, not the desired
backslash-r. I had to double escape the r, ie \\\release to make it
work. Grisha, did you generate the docs on BSD before, and if so is the
BSD sed different? Weird. Anyway it works for me now and since I'm the
one that's making the tarball this time around I guess thats all that
counts. ;)

Jim

[ Post a follow-up to this message ]

On Mon, 8 Aug 2005, Jim Gallacher wrote:

> I had to double escape the r, ie \\\release to make it work. Grisha, did
> you generate the docs on BSD before, and if so is the BSD sed different?

Yes, it was always done on FreeBSD before - it is quite likely that the
sed is different.... More likely it's make - the BSD make is _definitely_
different from GNU make.

Grisha

[ Post a follow-up to this message ]

Jim Gallacher wrote:
> Gregory (Grisha) Trubetskoy wrote:
> 
>
>
> Make sense to me.

And of course I really meant "Makes sense to me". 
 
>
>
> This schedule looks good to me. I've been putting the finishing touches
> on the docs for FileSession. (And making a couple of changes to
> Session.py so that the code matches the docs ;) ). Should be done in 30
> minutes.

In true (Monty) Python fashion you need to multiply everything I say by
10. (Or is it 20?).

Anyway, I've committed the documentation for FileSession. There are
still some rough edges in the docs I'd like to fix (more examples, a bit
of a blurb explaining exactly what session lockings is all about) but
nothing earth shattering, and not important enough to hold things up any
further.

I'm good to go for a beta release.

Regards,
Jim

[ Post a follow-up to this message ]