From: Richard M K. <kr...@pr...> - 2008-01-10 03:16:20
|
"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 |
From: Michael W. <mic...@fo...> - 2008-01-10 15:03:02
|
[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 |
From: Cyrus H. <ch...@bo...> - 2008-01-10 16:15:50
|
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 > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Richard M K. <kr...@pr...> - 2008-01-10 21:16:50
|
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 |
From: Nikodemus S. <nik...@ra...> - 2008-01-11 14:24:38
|
On 1/10/08, Richard M Kreuter <kr...@pr...> 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 |
From: Thiemo S. <th...@ne...> - 2008-01-11 16:30:58
|
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 |
From: Richard M K. <kr...@pr...> - 2008-01-12 23:51:03
|
"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 |
From: Nikodemus S. <nik...@ra...> - 2008-01-13 12:19:16
|
On 1/13/08, Richard M Kreuter <kr...@pr...> 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 |
From: Andreas F. <as...@bo...> - 2008-01-11 23:40:16
|
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 |
From: Nikodemus S. <nik...@ra...> - 2008-01-12 18:06:31
|
On 1/12/08, Andreas Fuchs <as...@bo...> 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 |
From: Richard M K. <kr...@pr...> - 2008-01-13 16:36:25
|
"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.) -- |
From: John V. <JVa...@ge...> - 2008-01-16 01:18:15
|
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 |
From: Brian M. <br...@ma...> - 2008-01-16 01:36:22
|
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 br...@ma... http://brian.mastenbrook.net/ |
From: Brown, Dr N. <Nig...@qm...> - 2008-01-13 23:20:00
|
> Date: Sun, 13 Jan 2008 18:06:46 +0200 > From: "Nikodemus Siivola" <nik...@ra...> > 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 |
From: Brown, Dr N. <Nig...@qm...> - 2008-01-13 23:41:15
|
> Date: Sat, 12 Jan 2008 18:50:37 -0500 > From: Richard M Kreuter <kr...@pr...> > Subject: Re: [Sbcl-devel] Thinking out loud about SBCL release policy > To: "Nikodemus Siivola" <nik...@ra...> > Cc: SBCL Devel-list <sbc...@li...> > Message-ID: <869...@pr...> >=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 |