Preparing for 0.9.13 release

Preparing for 0.9.13 release

[Rich Felker]

Hi everyone,

The major goals for 0.9.13 have been met and I'm hoping to prepare a
release sometime in the next few days. There are still a few issues I
want to address though, which I'm looking for some volunteers to help
with:

1. Tracking down orc's problem with resolver (see the thread with
   subject line "dn_expand() confuses postfix").

2. Writing tests for strftime and wcsftime (to catch any regressions
   from the recent field width additions or old bugs).

Please also report any other known or new bugs that have not been
fixed yet, in case I missed anything.

This release is intended to be the last set of major functional
changes before 1.0. New archs, additional simple legacy functions, and
other small things can still go in but after 0.9.13 I'd rather hold
off on big features until post-1.0 so we can instead focus on big
fixes, testing, etc. and have a solid 1.0 release.

Rich

Re: Preparing for 0.9.13 release

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2013-08-23 14:01:19 -0400]:
> This release is intended to be the last set of major functional
> changes before 1.0. New archs, additional simple legacy functions, and
> other small things can still go in but after 0.9.13 I'd rather hold
> off on big features until post-1.0 so we can instead focus on big
> fixes, testing, etc. and have a solid 1.0 release.

can you wait for long double changes
(i'm cleaning up the freebsd long double bithacks, it will take a few days)

Re: Preparing for 0.9.13 release

[Rich Felker]

On Fri, Aug 23, 2013 at 02:01:19PM -0400, Rich Felker wrote:
> Hi everyone,
> 
> The major goals for 0.9.13 have been met and I'm hoping to prepare a
> release sometime in the next few days. There are still a few issues I
> want to address though, which I'm looking for some volunteers to help
> with:
> 
> 1. Tracking down orc's problem with resolver (see the thread with
>    subject line "dn_expand() confuses postfix").

I think this is fixed now.

(commit 7211551e9ff7c8c9d1491856088cf832f2722bd6)

> 2. Writing tests for strftime and wcsftime (to catch any regressions
>    from the recent field width additions or old bugs).

I've caught some issues myself, but haven't actually done any heavy
testing. For most format specifiers, I think just basic sanity checks
would suffice. Anything that involves computation (like week-based
year stuff) would also benefit from boundary value checks. For time
zone related things, testing inputs created by both localtime and
gmtime, and with different types of time zone settings (GMT, POSIX
with and without DST, old and new zoneinfo) would be useful.

Rich