Re: 1.0 release?
On Mon, May 10, 2010 at 1:22 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote: On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 the nptl addition would warrant bumping the version to 0.10.0, yes. I don't think messing around with the major version and thus UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers. Its easy to keep the dynamic linker even if you bump major version: diff --git a/Rules.mak b/Rules.mak index fd0de49..8ff9f2d 100644 --- a/Rules.mak +++ b/Rules.mak @@ -108,7 +108,7 @@ MINOR_VERSION := 9 SUBLEVEL := 32 EXTRAVERSION :=-git VERSION := $(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL) -ABI_VERSION := $(MAJOR_VERSION) +ABI_VERSION := 0 ifneq ($(EXTRAVERSION),) VERSION := $(VERSION)$(EXTRAVERSION) endif ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 1.0 release?
On Tue, May 11, 2010 at 09:18:52AM +0200, Natanael Copa wrote: On Mon, May 10, 2010 at 1:22 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote: On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 the nptl addition would warrant bumping the version to 0.10.0, yes. I don't think messing around with the major version and thus UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers. Its easy to keep the dynamic linker even if you bump major version: ah, right. I thought you were talking about the library file-name. Bumping the so version is a different thing, we will do that, sure. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 1.0 release?
On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote: On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 the nptl addition would warrant bumping the version to 0.10.0, yes. I don't think messing around with the major version and thus UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 1.0 release?
On Mon, May 10, 2010 at 1:22 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote: On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 the nptl addition would warrant bumping the version to 0.10.0, yes. I don't think messing around with the major version and thus UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers. Would be nice with a beta tag/release unless there are more new features you want in there. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 1.0 release?
On Monday 10 May 2010 06:22:07 Bernhard Reutner-Fischer wrote: On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote: On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 the nptl addition would warrant bumping the version to 0.10.0, yes. I don't think messing around with the major version and thus UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers. Since when does being libc.so.0 have anything to do with the C library's version number? $ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 11 2009-09-28 00:56 /lib/libc.so.6 - libc-2.9.so I.E. my crufty old ubuntu 9.04 laptop is using version 2.9 of libc6. The 6 and the 2.9 are unrelated. libc5 vs libc6 were two completely different C library implementations. In that context, uClibc is libc0. That isn't a version number, that's as a replacement for the OSABI field in the Elf header (e_ident byte 7), because libc5 and libc6 needed to expose the difference at the path level to coexist on the same system, and thus couldn't use the ELF fields in the file for this. In that context, we're libc0, and we can be version 1.0 of libc0 just like glibc is version 2.9 of libc6. Going 0.10.0 is just silly. 1.0 means the project is feature complete, and can be used as a replacement for glibc. That appears to be the case. (It's actually been the case since 0.9.26, we're overdue. Busybox had its 1.0 release 5 years ago. Does that mean it ran out of stuff to do? No, it means it's not a toy anymore and we think you should be able to _use_ it.) Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 1.0 release?
On (10/05/10 00:02), Rob Landley wrote: So now that NPTL is in, it sounds like the next release should be either 1.0 or 1.0-pre. It is more or less feature complete, isn't it? yeah I have mentioned it on IRC couple of times to have next release be 1.0 It also sounds like a stable ABI for uClibc pretty much isn't in the cards, because when you change the uClibc .config you change the ABI. Also, there's nothing magical about the 1.0 release that'll stop people from wanting to switch to new kernel APIs and coming up with more efficient layouts for structures in response to that sort of thing... I'd also like to remind people of the awesome video: http://video.google.com/videoplay?docid=-5503858974016723264 April 19, 2007 Release Management in Large Free Software Projects - Martin Michlmayr (Debian) ABSTRACT: Time based releases are made according to a specific time interval, instead of making a release when a particular functionality or set of features have been implemented. This talk argues that time based release management acts as an effective coordination mechanism in large volunteer projects and shows examples from seven projects that have moved to time based releases: Debian, GCC, GNOME, Linux, OpenOffice, Plone, and X.org. Just thought I'd mention that... -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
