[slime-devel] The 1.0-alpha plan
Ahoy, I checked in a mkdist.sh shell script for creating a distribution. I made a "fake" release called 1.0alpha0 with it here: http://www.bluetail.com/~luke/misc/lisp/slime-1.0alpha0.tar.gz That's not a real release for distribution, just an example to see if we're missing anything. Two things that I know need doing before releasing an alpha tarball: Update the manual a bit - I'm on it. Write release notes. I've made a start in the NEWS file. It would be great if people could contribute notes about our ACL/CLISP/ABCL backends, and anything important I've missed about the others (e.g. what's the oldest LispWorks what we actually work with?) Is there anything else? If not, I was thinking of making an alpha1 tarball tomorrow or the next day and releasing it. -Luke
Luke Gorrie <luke@bluetail.com> writes:
Write release notes. I've made a start in the NEWS file. It would be great if people could contribute notes about our ACL/CLISP/ABCL backends, and anything important I've missed about the others (e.g. what's the oldest LispWorks what we actually work with?)
I think Bjørn Nordbø uses SLIME with LW 4.1. I updated the NEWS file. Perhaps we should have a PROBLEMS file too?
Is there anything else? If not, I was thinking of making an alpha1 tarball tomorrow or the next day and releasing it.
I'm tempted to remove the :sigio support for SBCL because it seems to cause problems for most people. Objections? Helmut.
On Wed, Jun 30, 2004 at 09:07:08AM +0200, Helmut Eller wrote:
I'm tempted to remove the :sigio support for SBCL because it seems to cause problems for most people. Objections?
Could it just be made non-default if there's no threading? I like :sigio (it usually works for me for whatever reason), since on my Mac it's the only way to get any Slime interactivity while a long computation is running. Also, there appears to be some sort of issue with :spawn and SBCL that slows down compilation considerably. Luke saw this on #lisp earlier today. On my Intel box, 3.0GHz, with SBCL 0.8.12 :sb-thread :sb-futex, and Linux 2.6.6, compiling McCLIM (with the ASDF system, executed from the Slime REPL) resulted in increasing pauses during the compile. Big pauses - 1-2 seconds, which is an eternity on that machine. There were multiple SBCL threads taking up a lot of CPU time. Emacs was not taking that much, so it wasn't just fontification. Running the same compile from the standard command line REPL was many times faster with no pauses. It'd be good if issues like these could be identified before release (either as a Slime problem to be fixed or an SBCL problem to notify the SBCL developers), because a threaded SBCL and :spawn communication-style is definitely going to be the default for the long run. -bcd
Brian Downing <bdowning@lavos.net> writes:
On Wed, Jun 30, 2004 at 09:07:08AM +0200, Helmut Eller wrote:
I'm tempted to remove the :sigio support for SBCL because it seems to cause problems for most people. Objections?
Could it just be made non-default if there's no threading? I like :sigio (it usually works for me for whatever reason), since on my Mac it's the only way to get any Slime interactivity while a long computation is running.
Sounds like the right idea to me, I updated swank-sbcl.lisp.
Also, there appears to be some sort of issue with :spawn and SBCL that slows down compilation considerably. [...] It'd be good if issues like these could be identified before release (either as a Slime problem to be fixed or an SBCL problem to notify the SBCL developers), because a threaded SBCL and :spawn communication-style is definitely going to be the default for the long run.
Definitely we want to find and fix problems like this before the 1.0 release, but it's not an "alpha-stopper" IMO. "Everyone knows" SBCL's compiler runs slowly so nobody'll blame us anyway. :-) -Luke
I've put a release candidate for 1.0alpha here: http://www.bluetail.com/~luke/misc/lisp/slime-1.0alpha.tar.gz Also slime.ps and slime.pdf (now prettier!) in the same directory. If you have a moment then please give it a once-over. If nobody finds any serious problems in the next hour or so then we can release it. I also tagged CVS with SLIME-1-0-ALPHA. -Luke
* Luke Gorrie <luke@bluetail.com> [2004-06-30T00:12+0200]:
I checked in a mkdist.sh shell script for creating a distribution. I made a "fake" release called 1.0alpha0 with it here:
FWIW, I do not like such kind of version numbers much. There are a small to medium pain for package maintainers ("Is '1.0' newer than '1.0alpha0'?"), and otherwise do not carry other information (I could expand this last point to a multi-page rant on request, but I count on common sense and general experience with software telling the same). There are enough "1.0" examples out there which are everything but stable, after all. In short, I would like to propose a compromise versioning scheme, namely the "n_1.n_2.\dots.n_m" format. Rationale: It still carries some hints^Winformation for users (mainly the (subjective) "graveness" of changes: major, minor, etc.), but is easy to grok for computers (which should be the main reason to use it), can be split into its hierarchical parts easily, etc. Example (with m=3, can be expanded if needed): So, I would label the release candidate "0.9.0", following bug-fixed versions would get "0.9.1", "0.9.2", etc. and once everyone is happy with it for a while, release it as "1.0.0". After that, immediately switch the unstable/currently-being-hacked-on/CVS version to "1.1.0", and start adding features. Backporting features/bugfixes would result in "1.0.x" releases, the next bigger releases would be called "1.2.0", and the hacking branch would be switched to "1.3.0" simultaneously. When ;) SLIME gains self-awareness, you as well could call it "2.0.0"... Summary: A version x.y.z * with (evenp y) means "stable"/released version * with (oddp y) means hacked-on version, not "officially" released, might be broken * with (plusp z) means minor fixes/backport of changes relative to "x.y.0" For users who know, the version numbers convey some information, for users who don't, it does not matter (they will pick the newest released one) and for computers/programs this format is easy to handle. I would also advise to use "x.y.0" and not contract it to "x.y", again for reason of simplicity in case a program needs to parse the version number for some reason (yes, I do know the credo "test for features, not for a version", but still it might be needed). I have been through this a couple of years ago with Glasgow Haskell Compiler head quarters (version numbers used to be a pain there, too), and the above described scheme now works well, I think (haven't heard complaints, at least). Of course, it was introduced too late and the damage was already there (just have a look at some shell scripts which parse ghc version information). Anyway, the above story just reflects my experience, feel free to ignore me. :) Cheers, Michael
Michael Weber <michaelw+slime@foldr.org> writes:
* Luke Gorrie <luke@bluetail.com> [2004-06-30T00:12+0200]:
I checked in a mkdist.sh shell script for creating a distribution. I made a "fake" release called 1.0alpha0 with it here:
FWIW, I do not like such kind of version numbers much. There are a small to medium pain for package maintainers ("Is '1.0' newer than '1.0alpha0'?")
Good! Nobody should package the alpha and beta versions anyway. :-) We can have the great version-numbering war after the 1.0 release. I think our current plan for that is okay. -Luke
participants (4)
-
Brian Downing -
Helmut Eller -
Luke Gorrie -
Michael Weber