[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190809054830.GG9017@brightrain.aerifal.cx>
Date: Fri, 9 Aug 2019 01:48:30 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: call it musl 1.2.0?
An idea crossed my mind today regarding the time64 conversion: should
we call the first release with it switched over musl 1.2.0 instead of
1.1.25? This would both reflect that there's something ABI-significant
(and a big functional milestone) about the release, and would admit
keeping a 1.1.x branch around for a while with backports of any major
bug fixes, since there will probably be some users hesitant to switch
over to 64-bit time_t right away before it's well-tested.
Looking at the roadmap goals that were set for 1.2.0 a while (a couple
years?) back now, most of them have been met:
- Out-of-tree builds
- Deduplication and cleanup of bits header system
- Deduplication of atomic asm logic
- AArch64 port
- RISC-V 64 port
- Significant improvement to previously-buggy/experimental archs
- External _FORTIFY_SOURCE implementation available
- External nss replacement available
- Unicode (mostly?) up-to-date
The ones that have not been met are:
- Locale overhaul (lots of subpoints)
- IDN support
- All documentation goals
- Midipix
All except which are (to say the least) somewhat drawn-out goals with
no end in sight.
Adding "64-bit time_t on 32-bit archs" to the above completed list,
and possibly also adding experimental riscv32, it sounds pretty
1.2.0-worthy to me.
Thoughts on this?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
