[Zope-dev] Zope 3.4 release policy

[Stephan Richter]

On Friday 01 August 2008, Martijn Faassen wrote:
> Thanks for doing all the work on KGS and the Zope 3.4.0 release.

Thank Marius for getting into it and giving me some incentive to work on it 
again too. :-)

> There are unfortunately a few things in this process that have me
> somewhat confused. I hope we can work out a way to clarify the process
> for 3.4.x and helping to clarify the process for 3.5.x.

I am confused too. :-) I am struggling between too-little time and formalizing 
the process. ;-)

> Firstly, could you add release dates to this page please?

I thought the same thing last night too when looking at the now rather lengthy 
list of releases on the intro page. Since the page is auto-generated, the 
generating script has to be updated. We have two options:

1. Add a release-date field to the [KGS] section in controlled-packages.cfg.

2. Parse KGS-HISTORY.txt. This would also allow us to generate change logs for 
each release.

Thoughts?

> http://download.zope.org/zope3.4/intro.html
>
> I know that 3.4.0c1 was the latest release from january 31st until at
> least may, when we moved Grok over to that list. Then rather silently
> and somewhat suddenly I find out there have been 4 more release
> candidate releases. What is driving these changes?

Marius started working on the KGS in the last week, since he is porting one of 
his apps from Zope 3.2 to 3.4. He needed to do a bunch of fixes to make it 
work. Also, he has set the goal for himself to fix the remaining failing 
tests. I also had some motivation to remove some deprecation warnings. So the 
last 4 candidates all happened in the last 2 weeks.

> There's a changelog now I saw you mention, where should I look?

zope.release has now a `KGS-HISTORY.txt` file.

> Here I was thinking Grok was synched up to the latest and greatest 3.4.x
> since its latest 0.13 release, but this is now not the case anymore. We
> had c1 which lasted so long that I had started to treat it as the final.

You pretty much are at the latest. :-)

> We have been in release candidate space for Zope 3.4 for a very long
> time; since january 31th. Do we really need 5 release candidates over a
> period of half a year? Would we really have been harmed if we'd released
> 3.4.0 final in, say, february, and were now doing 3.4.x releases?

The only reason I did not release in February was time. I signed up with Keas 
early in February and have been incredibly busy since then. Now that Marius 
is working on the release too, I want to honor his work and let him fix tests 
and make sure his app runs on Zope 3.4.

> What's the current plan for the final? What are the conditions that need to 
> be reached to make a final release? 

From my point of view, my conditions would be:

- Let Marius ensure his app works with Zope 3.4.

- Let Marius finish fix the final test failures. He invested already a lot of 
time. (I know, because I gave up on the final failing ones.)

- Nice to have: Update all packages in the KGS to their latest bug fix 
release.

My larger concern is to make the release process much smoother and automated, 
so that the burden of making a release becomes much smaller. I think the 
following scripts could be written without too much effort:

- Setup a buildbot for KGS releases. I think Marius set one up already. The 
test output could become part of some page linked from "intro.html". I am 
thinking in particular of the total number of tests (marketing) and the 
failures. 

- Upload the KGS-HISTORY.txt and parse it for the release date and changelog. 
(Note that this parser could be written to understand our CHANGES.txt format 
and we could even pull in Changelogs from all the updated packages!)

- Add the date and changelog info to intro.html.

- When uploading a new version of the KGS, automatically update the Zope 3 
tree branch as well and create a release tag. Uses also the changelog 
information for the tree CHANGES.txt file.

- Automatically create a Zope 3 tree TAR ball and upload it to zope.org. 
Generate a link for it in the intro page as well.

- Automatically create a release E-mail and send it to zope-dev and 
zope-users.

This should not be more than a days work for one of the core developers.

With this in place, cutting a release would become a matter of 
calling "/bin/upload" from the "zope.release" package.

What do you guys think?

-- 
Stephan Richter
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"