On Mon, May 04, 2009 at 10:20:04AM -0700, Alan Irwin wrote:
> On 2009-05-04 09:16-0400 Hazen Babcock wrote:
> > Alan W. Irwin wrote:
> >> Hi Hazen:
> >> [...]It appears Mac OS X users of 5.9.3 are going to have to patch their systems
> >> for the entirety of the 5.9.3 release cycle. To reduce that user pain as
> >> much as possible, I suggest that release cycle should be shortened as much
> >> as possible. Thus, Hazen, once you are happy with your Mac OS X tests, I
> >> suggest you do a full 5.9.4 release today (Sunday) or tomorrow remembering
> >> to repeat all the version-specific stuff in README.Release_Manager_Cookbook
> >> for 5.9.4.
> >> Meanwhile, every other developer should refrain from commits to give Hazen
> >> a
> >> clear field to deal with this simple, but nevertheless embarrassing issue.
> > Well I hope someone will step up and fix the example 32 problem I mentioned.
> That example is a special one which is still being developed/considered.
> >From the commit message for examples/c/x32c.c
> "For now this is built automatically, but not included in the test suite
> or propagated to other languages. Please leave this way until it has
> been discussed further on plplot-devel."
> Therefore, you should ignore this example for at least this bug-fix release
> or patch.
> I have just mentioned the possibility of a patch instead of a formal release
> because I think speed is essential. So if you don't have time to do a
> formal 5.9.4 release today (with especial care taken to get the version
> numbers and everything that depends on them like the website updated
> consistently) we could propagate a macosx patch to 5.9.3 (called, e.g.,
> plplot-5.9.3.macosx.patch which should be largely self-explanatory) instead.
> If you prefer the patch approach, I would need you to first create a tested
> aqt.rc.in file and commit it. After that I could do everything else, i.e.,
> generate the patch, propagate it to SF, make the associated announcement,
> etc. This approach adds a patch file that macosx users have to download and
> apply so it is probably not as good as a formal 5.9.4 release. However, a
> formal 5.9.4 release takes more time, and if you are tired or rushed there
> are some possibilities for screwing up the version numbers in an
> inconsistent way unless you religiously follow
> Let me know which approach you want to do.
Maybe a patch now and a short release cycle? There are a number of
outstanding issues (e.g. the qt visibility issue, pngcairo segfaults
when repeatedly calling plinit / plend ) which might merit a fairly
speed next release.