On Feb 18, 2014, at 5:46 PM, Jody Lee Bruchon <j...@jodybruchon.com> wrote:
> On February 18, 2014 7:23:11 PM EST, Khem Raj <raj.k...@gmail.com> wrote: >> inclusion into master. Secondly, would >> it be just fine if the release is made >> in form of a git branch and no tarballs? > > I would like to point out that the last release of uClibc with a version > number was released 2012-05-15. there is no need to state the obvious. > This is a 21-month gap since the last release, which usually leads people to > believe that the project is stagnating or no longer maintained (which it may > have been, since there were no Git commits in 2013 save for a few in early > January.) It also forces anyone trying to release to come up with their own > way to handle versioning. > > There are a great number of fixes since the last numbered release and I for > one would greatly appreciate having at least a "testing" release with a > bumped version number to use. Other than the ldso stat call problem I > reported a couple of weeks ago, uClibc trunk has been working fairly well, > and most bugs I run into are the typical growing pains of toolchain building > from scratch rather than uClibc problems. so get going start testing git/master and report issues or successes you have. help in testing it out, run uclibc test suites or any others you have setups for > > I don't think that a "Git release" is appropriate for these reasons. Besides, > if you did tag a Git commit with a version number, there's also no reason not > to put out a tarball to go with it, right? it needs some work whereas with git you can download the tars from cgit, but not a big issue. We can release tar balls too. > > -Jody Bruchon _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc