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" _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
