* call it musl 1.2.0?
@ 2019-08-09 5:48 Rich Felker
2019-08-09 15:30 ` Khem Raj
0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2019-08-09 5:48 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: call it musl 1.2.0?
2019-08-09 5:48 call it musl 1.2.0? Rich Felker
@ 2019-08-09 15:30 ` Khem Raj
2019-08-09 15:54 ` Rich Felker
0 siblings, 1 reply; 3+ messages in thread
From: Khem Raj @ 2019-08-09 15:30 UTC (permalink / raw)
To: musl
On Thu, Aug 8, 2019 at 10:48 PM Rich Felker <dalias@libc.org> wrote:
>
> 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.
>
I like the idea.
what do you think about 2.0
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: call it musl 1.2.0?
2019-08-09 15:30 ` Khem Raj
@ 2019-08-09 15:54 ` Rich Felker
0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2019-08-09 15:54 UTC (permalink / raw)
To: musl
On Fri, Aug 09, 2019 at 08:30:03AM -0700, Khem Raj wrote:
> On Thu, Aug 8, 2019 at 10:48 PM Rich Felker <dalias@libc.org> wrote:
> >
> > 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.
> >
>
> I like the idea.
Thanks for the feedback!
> what do you think about 2.0
I generally don't like version inflation, and to me major versions
still signify heavy, usually-incompatible changes. time64 is a big
deal for preserving the long-term viability of the platform, but it's
not something users will immediately get new or different outward
behavior out of. If anything, in the short term it's going to be a bit
of a headache, fixing code making bad assumptions like ability to use
syscalls with time arguments directly or even just stuff using %ld to
format time_t values.
What I might envision for a "2.0" is a refactorization of library to
kernel glue and reorganization of directory structure that makes musl
capable of filling more of a newlib-like role. I'm still not even sure
if it makes sense to do that, but I'm using it here as an example of
the scope/order of magnitude.
Rich
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-08-09 15:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-09 5:48 call it musl 1.2.0? Rich Felker
2019-08-09 15:30 ` Khem Raj
2019-08-09 15:54 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).