sbcl-devel

"Nikodemus Siivola" writes:
> What I would like to see would be a "real beta period":
>
> * Freeze 1.1.beta.1. Announce it.
>
> * Let people test it for a month or so. If there are no regressions
> or major complaints, call it 1.1.0. During this time bleeding edge
> development proceeds normally.
>
> * If there ("if", hah!) is anything worth fixing, make a new beta:
> 1.1.beta.2 -- either with backported fixes, or take the next monthly,
> whichever seems like a better bet at the time.
>
> * Repeat as necessary -- hopefully finishing the process in less then
> 4 iterations...
>
> How does this sound? Would the better testing be worth the extra hassle?
> Just to clarify, I'm more interested in a solid beta period for every 1.X
> release then I am in timeboxing the same -- but I think there would be
> benefits in timeboxing the period last 1.X release and the start of beta
> period for next.
I like both ideas (beta periods for point releases and a schedule for
point releases).
For the periodicity, I think a good target for the point releases might
be two times per year: since we need people to test SBCL in order for a
beta test period to be worthwhile, ISTM that a too-frequent period for
point releases would be too much hassle for people for whom testing a
new SBCL is a big deal.
--
RmK

[erroneously sent as PM only]
On Jan 9, 2008, at 21:03 , Nikodemus Siivola wrote:
> I like our monthly release policy, but I think we're kidding ourselves
> if we pretend they are tested even remotely solidly. More then a
> random
> revision mid-month, sure, but I don't think as many users as we hope
> put SBCL put through its paces during the freeze period -- and we
> don't
> have a solid list of things to shake at it ourselves either before
> we call
> it good.
It would be the first time (that I know of) that shifting around
release cycles or version naming will change that. If you want
better tested releases, you can't rely on random users alone.
> Monthly release cycle is also extremely rapid (I think) for people
> for whom
> it means updating applications to when there are incompatible
> changes, and
> even if there is nothing to fix, just testing a new SBCL for use
> with their
> applications every month is probably a bit much a sizable
> percentage of our
> users (users, please comment on this!)
Maybe a monthly release cycle is rapid, but I like the regular
releases. I am free to (and I do) ignore releases and test only
every other, or pick those which have interesting improvements to
me. At least new features get pushed out regularly. Every two
months would be good as well, I guess. But opting for longer release
cycles means that more new features are cramped into a release, and
it might become harder to isolate interactions between them. Think
"I want feature X, but feature Y is currently broken": if X and Y are
in the same release, I have to resort to CVS?
> * Freeze 1.1.beta.1. Announce it.
Disclaimer: I believe that version numbers are mostly for machines,
to be able to sort releases, have automatic update procedures, etc..
For me as a user, they are mostly opaque tags. I will perhaps
remember that "sbcl-0.8.16 was stable, and useful for ancient
kernels", or "I am running foo-3456alpha2 without problems", but
that's about it. They have no other meaning. "1.0" means nothing
more to me than "0.9.42" in terms of bug-freeness or stability (case
in point: linux kernels with low patchlevels numbers, OS X 10.5.0,
etc.). On the other hand, a developer might want to be able to spot
easily that 1.3.42 is some random CVS release.
How do you sort "1.1.beta.1" vs. "1.1.0"? This will inflict pain on
packagers. You might say that you don't care (fair enough), or that
they should not package "1.1.beta.1" (it will happen anyway), but
this is quite avoidable.
If you want to go ahead with your proposal, at least choose some
machine-friendly scheme, like even minor numbers (with versions like:
major.minor.patchlevel) for public releases vs. odd minor numbers for
"beta releases". Or rather, odd minor versions for CVS commits.
E.g., "1.1.42" means "42nd commit in preparation for 1.2.0". Then
"1.2.0" is released, CVS becomes "1.3.0", ..., "1.3.10", etc.. Then
"1.4.0" is released.
Michael

I tend to agree with Michael's numbering comments and I don't like the
idea that 1.1.0 is different from 1.1. What's next? 1.1.0.0?
Also, I think the monthly release thing is a useful construct to have
stable-ish versions on a consistent basis. What I would like to see,
however, is more 2-digit (well, 2-part-number anyway) releases. The
1.0 release generated a lot of buzz and there's been a lot of good
work since then. IMO, it makes perfect sense to plan for a 1.1 release
based on things that are already in the tree with the notion that this
release would get a bit more testing than usual and, importantly, a
fresh set of binary builds for all platforms we care about (and maybe
some we don't). But I don't think we need to change the whole way we
do releases to accomplish this.
Cyrus
On Jan 10, 2008, at 1:24 AM, Michael Weber wrote:
> [erroneously sent as PM only]
>
> On Jan 9, 2008, at 21:03 , Nikodemus Siivola wrote:
>
>> I like our monthly release policy, but I think we're kidding
>> ourselves
>> if we pretend they are tested even remotely solidly. More then a
>> random
>> revision mid-month, sure, but I don't think as many users as we hope
>> put SBCL put through its paces during the freeze period -- and we
>> don't
>> have a solid list of things to shake at it ourselves either before
>> we call
>> it good.
>
> It would be the first time (that I know of) that shifting around
> release cycles or version naming will change that. If you want
> better tested releases, you can't rely on random users alone.
>
>> Monthly release cycle is also extremely rapid (I think) for people
>> for whom
>> it means updating applications to when there are incompatible
>> changes, and
>> even if there is nothing to fix, just testing a new SBCL for use
>> with their
>> applications every month is probably a bit much a sizable
>> percentage of our
>> users (users, please comment on this!)
>
> Maybe a monthly release cycle is rapid, but I like the regular
> releases. I am free to (and I do) ignore releases and test only
> every other, or pick those which have interesting improvements to
> me. At least new features get pushed out regularly. Every two
> months would be good as well, I guess. But opting for longer release
> cycles means that more new features are cramped into a release, and
> it might become harder to isolate interactions between them. Think
> "I want feature X, but feature Y is currently broken": if X and Y are
> in the same release, I have to resort to CVS?
>
>> * Freeze 1.1.beta.1. Announce it.
>
> Disclaimer: I believe that version numbers are mostly for machines,
> to be able to sort releases, have automatic update procedures, etc..
> For me as a user, they are mostly opaque tags. I will perhaps
> remember that "sbcl-0.8.16 was stable, and useful for ancient
> kernels", or "I am running foo-3456alpha2 without problems", but
> that's about it. They have no other meaning. "1.0" means nothing
> more to me than "0.9.42" in terms of bug-freeness or stability (case
> in point: linux kernels with low patchlevels numbers, OS X 10.5.0,
> etc.). On the other hand, a developer might want to be able to spot
> easily that 1.3.42 is some random CVS release.
>
> How do you sort "1.1.beta.1" vs. "1.1.0"? This will inflict pain on
> packagers. You might say that you don't care (fair enough), or that
> they should not package "1.1.beta.1" (it will happen anyway), but
> this is quite avoidable.
>
> If you want to go ahead with your proposal, at least choose some
> machine-friendly scheme, like even minor numbers (with versions like:
> major.minor.patchlevel) for public releases vs. odd minor numbers for
> "beta releases". Or rather, odd minor versions for CVS commits.
> E.g., "1.1.42" means "42nd commit in preparation for 1.2.0". Then
> "1.2.0" is released, CVS becomes "1.3.0", ..., "1.3.10", etc.. Then
> "1.4.0" is released.
>
>
> Michael
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Michael Weber writes:
> Maybe a monthly release cycle is rapid, but I like the regular
> releases. I am free to (and I do) ignore releases and test only
> every other, or pick those which have interesting improvements to
> me. At least new features get pushed out regularly. Every two
> months would be good as well, I guess. But opting for longer release
> cycles means that more new features are cramped into a release, and
> it might become harder to isolate interactions between them. Think
> "I want feature X, but feature Y is currently broken": if X and Y are
> in the same release, I have to resort to CVS?
I don't think Nikodemus was proposing stopping the monthly releases. As
I understood his message, he was calling for an additional cycle of
somewhat more significant releases preceded by a test period longer than
5 days.
At any rate, if people are agreed that it's about time for a 1.1
release, I can't see it hurting anything to make a 1.1-beta branch, to
announce a month long test period for it, and to ask users to look for
bugs and regressions while it's in beta. If this brings testers out of
the woodwork, then we can debate whether it's worth the hassle.
--
RmK

On 1/10/08, Richard M Kreuter <kreuter@...> wrote:
> I don't think Nikodemus was proposing stopping the monthly releases. As
> I understood his message, he was calling for an additional cycle of
> somewhat more significant releases preceded by a test period longer than
> 5 days.
Yes. Let me take a step back and restate things in a clearer manner.
* Current release cycle is Good. Let's keep it.
* Every once and a while we want to increment the second digit
instead of the third. This can be a timeboxed thing, or a purely
by-the-seat-of-our-pants thing. I don't really care. What I do care
about, and claim, is that these "point releases" deserve more testing
then monthly timeboxed releases do.
I think they deserve a semiformal beta-period, and I strongly believe that
the beta versions should be clearly identified as such by the version
number. I also think that the barrier to extending the beta period should
be fairly low: if anything but the most trivial fixes go in, we should
make a new beta release and do another round of testing.
I agree with the expressed sentiment that 1.X == 1.X.0, so the version
numbering scheme obviously demands some thought. The exact scheme is
unimportant, as long as it is simple enough, and something everyone can
live with.
Maybe
1.0.X.Y -- this is where we are now
1.1-beta.X -- beta-series for 1.1
1.1.0.0 -- RELEASE -- drop the zeroes if you want to
1.1.0.X -- reserved for backported fixes, etc, should intrepid
maintainers for such appear -- may turn out to be unused.
1.1.X.Y -- next development series of monthly timeboxed releases,
where X>0.
1.2-beta.X -- beta-series for 1.2
-- maybe something else.
IMO a much harder question is what to do during the beta period, if
we instigate one. Halt normal development? Do it on a branch? Do the
beta on a branch, and normal development in the HEAD?
> At any rate, if people are agreed that it's about time for a 1.1
> release, I can't see it hurting anything to make a 1.1-beta branch, to
> announce a month long test period for it, and to ask users to look for
> bugs and regressions while it's in beta. If this brings testers out of
> the woodwork, then we can debate whether it's worth the hassle.
It's true that we're not eternally committed to whatever we come up
with.
Cheers,
-- Nikodemus

Nikodemus Siivola wrote:
[snip]
> 1.0.X.Y -- this is where we are now
> 1.1-beta.X -- beta-series for 1.1
> 1.1.0.0 -- RELEASE -- drop the zeroes if you want to
> 1.1.0.X -- reserved for backported fixes, etc, should intrepid
> maintainers for such appear -- may turn out to be unused.
> 1.1.X.Y -- next development series of monthly timeboxed releases,
> where X>0.
> 1.2-beta.X -- beta-series for 1.2
>
> -- maybe something else.
>
> IMO a much harder question is what to do during the beta period, if
> we instigate one. Halt normal development? Do it on a branch? Do the
> beta on a branch, and normal development in the HEAD?
Shutting down normal development for more than a few days is IMHO
a bad idea. Everything else in this proposal sounds agreeable to me.
Thiemo

"Nikodemus Siivola" writes:
> 1.1.0.X -- reserved for backported fixes, etc, should intrepid
> maintainers for such appear -- may turn out to be unused.
This suggestion got me thinking about how to do maintenance on otherwise
frozen releases. It occurs to me that for a large amount of the system,
we could issue bugfixes as files of Lisp code that can be loaded into
SBCL, rather than whole new snapshots with a different version number.
ISTM this has several virtues:
* this makes patch installation relatively convenient for users: they
don't have to download and build a whole new SBCL, just to load (or
maybe compile-and-load) a set of patches, and dump a core if they
wish.
* We wouldn't need to issue new SBCL builds for each platform when a bug
is fixed in the point release, just publish a tarball/zipfile of all
patches.
* When people report bugs, we can ask them to try to reproduce the bug
using the published X.Y.0.0 build, along with patches we publish,
which should reduce the number of ways that somebody's SBCL can be
randomly different from the proper releases.
* So long as bugfixes don't break FASL formats, not bumping the version
number for a release's maintenance patches means that users won't have
to recompile all their stuff every time they want a bugfix, which I
would imagine to be nice for people using such releases in production.
* Of course not everything can be patched this way, but perhaps the
limits of runtime redefinition could be a reasonable constraint on
what sort of maintenance is done on a point release.
With that in mind, I wrote a tiny system to support working with sets of
patches, designed more or less for patching SBCL, but possibly useful
for other things, too:
http://www.progn.net/static/cl/sb-patch/
If people think a patch facility like the above is not too bad an idea,
I envision it being a contrib module eventually. (One issue with the
code right now is that I add an :AFTER method to PERFORM on a LOAD-OP
and a SYSTEM, but it's not clear who owns what in ASDF's class space, so
I think it might be best to have all the contribs that are ASDF systems
be instances of some SBCL-specific subclass of SYSTEM.)
Any comments?
--
RmK

On 1/13/08, Richard M Kreuter <kreuter@...> wrote:
> Any comments?
I wrote a long reply which I deleted.
To summarize:
* I like the idea of a patch system.
* I have several questions and a few ideas about how the system should
work, and how not -- but I did not want to derail the conversion into
the minefield of details just yet.
* If we're thinking of pushing out 1.1, I would be OK with experimenting
with a patch system in the context of that -- and delaying the release
till the system is in place.
* I was also thinking that hashing out the patch system might be a nice
place for a mini Git experiment -- either using a shared repository,
or saying that the patch system lives in repo X, and people wanting
play should pull from there and send patches to the list. (I think
the patch system would benefit from a public experimentation ground,
but I don't think we need all the experiments in mainline history
in CVS.)
Finally, prior art:
* http://common-lisp.net/project/bknr/static/lmman/patch.xml#patch
* http://www.lispworks.com/downloads/patch-selection.html
* http://www.franz.com/support/patches/
Also, IIRC Raymond Toy at one point planned to use ASDF-INSTALL as a
patch system for CMUCL, but I could not immediately find anything about
that.
Cheers,
-- Nikodemus

On Jan 11, 2008, at 15:24, Nikodemus Siivola wrote:
> Maybe
>
> 1.0.X.Y -- this is where we are now
> 1.1-beta.X -- beta-series for 1.1
> 1.1.0.0 -- RELEASE -- drop the zeroes if you want to
> 1.1.0.X -- reserved for backported fixes, etc, should intrepid
> maintainers for such appear -- may turn out to be
> unused.
> 1.1.X.Y -- next development series of monthly timeboxed releases,
> where X>0.
> 1.2-beta.X -- beta-series for 1.2
>
> -- maybe something else.
A bit of historical data: This would not be the first time SBCL has
done a beta period (then named alpha and pre (-:) for a point-X
release. How those were handled, I don't know exactly. The releases in
question were 0.8 and 0.7, and the version numbers looked like this:
0.7.13.32 - what came before
0.pre8.x and 0.pre7.x - alpha series
0.8alpha.x - even more alpha series (I have no idea why this was
introduced)
0.8.0 - the release
0.8.0.y - development versions in the 0.8.0 series
I would suggest sticking to this numbering scheme because there are
exceptions for it already in place in autobench and I would hate
having to touch this code for yet another numbering scheme (-:
> IMO a much harder question is what to do during the beta period, if
> we instigate one. Halt normal development? Do it on a branch? Do the
> beta on a branch, and normal development in the HEAD?
I wasn't exactly "there", but reading the history I see that during
the 0.pre8 and .pre7 times, things still were being developed, but
focus was more on bug fixing than on more features. The pre-period
seems to have been handled more or less like a regular release period
itself, with less features and more bug fixes. Maybe repeat that? It
seems to have worked well for those two releases (-:
Cheers,
--
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

On 1/12/08, Andreas Fuchs <asf@...> wrote:
> I wasn't exactly "there", but reading the history I see that during
> the 0.pre8 and .pre7 times, things still were being developed, but
> focus was more on bug fixing than on more features. The pre-period
> seems to have been handled more or less like a regular release period
> itself, with less features and more bug fixes. Maybe repeat that? It
> seems to have worked well for those two releases (-:
You mean, instead of 1.0.X, release 1.pre1, and restraint development
to well-tested bugfixes for the month?
Cheers,
-- Nikodemus

"Nikodemus Siivola" writes:
> * If we're thinking of pushing out 1.1, I would be OK with experimenting
> with a patch system in the context of that -- and delaying the release
> till the system is in place.
The patch loading program I've published is fairly standalone: it's one
file, along with two patches to hook it into REQUIRE for the contribs.
So if people feel like doing a 1.1 release now and trying a patch
facility/protocol after the release is out, that should be possible:
just publish the patches along with loading program. (If this kind of
patching scheme doesn't work, the idea can be discarded and X.Y.0.Z
releases can be made from the VC system, of course.)
> Finally, prior art:
>
> * http://common-lisp.net/project/bknr/static/lmman/patch.xml#patch
>
> * http://www.lispworks.com/downloads/patch-selection.html
>
> * http://www.franz.com/support/patches/
I've looked at these, and took a couple of ideas from Allegro's
defpatch. AFAICT, the LispM patch facility was tied into other things
(the editor, the defsystem, etc.) in ways I'm not going to try to
emulate right now. (I think people who want that stuff might be able to
write it, subject to the limitations of their defsystems and editors.)
--

Hi, I'm sorry if this is a stupid question, but is there a way to change
the working directory in SBCL? That is, the place Lisp will look if you
provide a relative pathname to load, with-open-file, probe-file, etc.?
I see *default-pathname-defaults*, and that it is setfable, but it
doesn't seem to change the directory for file access.
Thanks,
John

On Jan 15, 2008, at 7:17 PM, John Valente wrote:
>
> Hi, I'm sorry if this is a stupid question, but is there a way to
> change
> the working directory in SBCL? That is, the place Lisp will look if
> you
> provide a relative pathname to load, with-open-file, probe-file, etc.?
> I see *default-pathname-defaults*, and that it is setfable, but it
> doesn't seem to change the directory for file access.
Hi John,
Try SB-POSIX:CHDIR (after loading SB-POSIX):
(require :sb-posix)
(sb-posix:chdir "/")
--
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

> Date: Sun, 13 Jan 2008 18:06:46 +0200
> From: "Nikodemus Siivola" <nikodemus@...>
> Subject: Re: [Sbcl-devel] [Sbcl-help] Thinking out loud about SBCL
> release policy
<snip>
> * While we don't have any users actively clamoring for stable
> releases, I do believe we have users who would prefer to use
> such. No numbers, though.
As an occasional user listening in on the list rather than a developer I
think having identifiable preferred stable releases makes SBCL more
useable in a production environment. Particularly where risk management
requires some documentation of suitability for use which I think is made
defensible by some sort of 'stable' tag.=20
Regards
Nigel

> Date: Sat, 12 Jan 2008 18:50:37 -0500
> From: Richard M Kreuter <kreuter@...>
> Subject: Re: [Sbcl-devel] Thinking out loud about SBCL release policy
> To: "Nikodemus Siivola" <nikodemus@...>
> Cc: SBCL Devel-list <sbcl-devel@...>
> Message-ID: <8690.1200181837@...>
>=20
> "Nikodemus Siivola" writes:
>=20
> > 1.1.0.X -- reserved for backported fixes, etc, should intrepid
> > maintainers for such appear -- may turn out to be=20
> > unused.
>=20
> This suggestion got me thinking about how to do maintenance=20
> on otherwise frozen releases. It occurs to me that for a=20
> large amount of the system, we could issue bugfixes as files=20
> of Lisp code that can be loaded into SBCL, rather than whole=20
> new snapshots with a different version number. ISTM this has=20
> several virtues:
>=20
> * this makes patch installation relatively convenient for users: they
> don't have to download and build a whole new SBCL, just to load (or
> maybe compile-and-load) a set of patches, and dump a core if they
> wish.
As a user vote for patches I've found the patching system introduced
into V3 of Corman Lisp useful.
The only issue I've had with the Corman system is that getting past our
corporate firewall
for automated patching is in the too hard basket so I have to locally
mirror the patch directory.
>From the Corman Lisp User Manual:
"An auto-update feature, enabled by default in the Corman Lisp IDE, will
keep your
Corman Lisp installation up to date with patches, documentation updates,
etc. Each
time the IDE starts it will check the Corman Lisp web site
(www.cormanlisp.com)
for new patch files. The patch level of these files will be compared
against the patch
level of your installed version, and if the patches are newer, you will
be prompted to
upgrade to the newer patch level. If you choose to upgrade, the new
patches will be
loaded and installed automatically, and a new CormanLisp.img file will
be
generated. Previous files will be backed up, and may be used later if
for some reason
you choose to roll back (undo) a patch.
The Auto-Update facility may be used from the Corman Lisp console as
well, but
does not run automatically (by default). You may make changes in the
init.lisp
file to either disable Auto-Update in the IDE, or enable it in the
console, as desired."
Regards
Nigel