If our Trac milestones are still correct, it's time to start preparing a release again!
Does anybody have local changes which urgently require a release? If so, please commit, so we can start the release process.
In the mean time, it'd be great if a volunteer would step up to update CHANGES and the 0.24 release notes page.
Thanks in advance!
Bye,
Erik.
On 12/31/10 2:50 PM, Erik Huelsmann wrote:
If our Trac milestones are still correct, it's time to start preparing a release again!
Does anybody have local changes which urgently require a release? If so, please commit, so we can start the release process.
In the mean time, it'd be great if a volunteer would step up to update CHANGES and the 0.24 release notes page.
I'm up for a release: I'll start in on the CHANGES I know about over the next few days, collecting what exists in my various Mercurial patch queues. I'll try to fixup the newly add 'tools' with documentation, but don't need to get this finished with a release, as anyone who would really care about that level of detail would be tracking us in [svn][common-lisp.net] or [hg][abcl-dynamic-install.googlecode.com]
A MUST-FIX for abcl-0.24.0 for me would be [making the compiler correct for stack inconsistencies in Alexandria-CURRENT][1]. I have already corrected to the fallback to interpreted version in DEFUN, so I'll just add code to do the same for top level forms as well. Unless someone is going to fix the compiler for the release?
Once ticket #117 closes I have patches to use [the new ability to create synthetic java interfaces using the new classwriter][2] to add callbacks written to native C interfaces via JNA to CFFI.
[1]: http://trac.common-lisp.net/armedbear/ticket/117 [2]:http://code.google.com/p/abcl-dynamic-install/source/detail?r=2ff83d35b6b3bc...
common-lisp.net: http://trac.common-lisp.net/armedbear/browser abcl-dynamic-install.googlecode.com: http://code.google.com/p/abcl-dynamic-install/source/list
On 31 December 2010 19:41, Mark Evenson evenson@panix.com wrote:
A MUST-FIX for abcl-0.24.0 for me would be [making the compiler correct for stack inconsistencies in Alexandria-CURRENT][1]. I have already corrected to the fallback to interpreted version in DEFUN, so I'll just add code to do the same for top level forms as well. Unless someone is going to fix the compiler for the release?
I think it would be healthy to block the release until such stack problems are corrected. We should be able to notice such stack inconsistencies if patches are tested according to the proposed process we have in place (including running the ansi-tests). Continuing to push in stack-consistency-breaking changes and falling back to interpreter when release pressure arises doesn't sound all that sane to me.
From [the NEWS on my patches to ASDF-INSTALL able packages][1]:
December 31, 2010 Happy New Year, ABCL!
Patch [CFFI][] to work with JNA on abcl-0.24.0 or greater
Patch [Bordeaux Threads 0.8.0][bt] to work with ABCL 0.24.0
[1]: http://slack.net/~evenson/abcl/asdf-installable-patches/ CFFI: http://slack.net/~evenson/abcl/cffi-abcl-20101231a.diff bt: http://slack.net/~evenson/abcl/bordeaux-threads-abcl-20101204a.diff
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Mark Evenson -
Ville Voutilainen