From: William H. N. <wil...@ai...> - 2006-08-14 13:24:39
|
Thinking about binary incompatibilities (another day, another increment to +FASL-FILE-VERSION+) my thoughts naturally turn to version numbers... We seem to be short of dramatic excuses for version 1.0, in part because you all are too good at slipstreaming harmless little changes (such as unicode, threading, mswindows support, or the fopcompiler) into minor releases without messing up stability for those of us still contentedly using the old features. However, approaching 0.9.20 is starting to look like a good enough excuse to me. Would it be appropriate to pick an arbitrary month, probably late in this year, and plan to call its ordinary late-in-the-month release version 1.0? I nominate October or November. (December 25th would be a cute choice but probably not the most practical, since people tend to be distracted by travel and whatnot.) -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Nikodemus S. <nik...@ra...> - 2006-08-14 15:29:48
|
William Harold Newman <wil...@ai...> writes: > Would it be appropriate to pick an arbitrary month, probably late in > this year, and plan to call its ordinary late-in-the-month release > version 1.0? I nominate October or November. (December 25th would be a > cute choice but probably not the most practical, since people tend to > be distracted by travel and whatnot.) Sounds good to me. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Christophe R. <cs...@ca...> - 2006-08-14 15:56:33
|
William Harold Newman <wil...@ai...> writes: > Thinking about binary incompatibilities (another day, another > increment to +FASL-FILE-VERSION+) my thoughts naturally turn to > version numbers... Whoops, yes, sorry. I might make that happen some more this month if I can get round some more PCL nastinesses. > Would it be appropriate to pick an arbitrary month, probably late in > this year, and plan to call its ordinary late-in-the-month release > version 1.0? I nominate October or November. (December 25th would be a > cute choice but probably not the most practical, since people tend to > be distracted by travel and whatnot.) I'm generally positive about this. (This actually matches the vague handwavy time I mentioned to people 18 months ago, so clearly I have not only telepathic debugging skills but also working precognition...) What I would like to see before agreeing completely is a vague consensus about what happens after 1.0. Is it * 1.0.1 released one month later, no guarantees over source / binary compatibility with 1.0; or * 1.0.1 released several months later, no guarantees over source / binary compatibility with 1.0; or * 1.1.0 released one month later, no guarantees over source / binary compatibility with 1.0; a branch for 1.0 maintenance set up for those who want to support 1.0 with bugfixes; or * something else ? Put another way, what does 1.0 actually mean? (Does it mean that we have to document all the bits we have lazily not been documenting? What about bits we don't want to document because they're not finished?) This sounds more Angsty than it should. As I say, I'm generally positive, really... :-) Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2006-08-18 09:10:44
|
Juho Snellman <js...@ik...> writes: > * 1.0.1 released one month later, no guarantees over source / binary > compatibility with 1.0. But we encourage people releasing > non-portable internals-using software to maintain > backwards-compability with 1.0 at least until the release of 1.1, > expected to happen about a year later. This sounds plausible. (In some sense, it's the same-old aggressive philosophy as the 0.9.x development: if you're using internals, it's your responsibility to maintain as much backwards-compatibility as you want.) It's more work for those writing and maintaining libraries which need internals, which is in some sense where the work needs to be placed; on the other hand, as someone who helps support some of those libraries, even I weary somewhat of the compatibility treadmill, so I'll just say that post-1.0 it would be nice to think about providing nice exported interfaces for some of the internals. The other side of this coin is worth examining too, though it's somewhat harder to get hard data. In the past, there have been anecdotal reports of people who have rejected SBCL for their use because of (a) immmaturity and/or (b) instability. Some of them might even be reading this list, but if they're not, maybe readers know someone in that situation. It might be interesting to know if the kind of post-1.0 development policy that Juho proposes would work for those people, and if not, why not. Cheers, Christophe |
From: William H. N. <wil...@ai...> - 2006-08-21 19:30:28
|
Ah, yes, I suppose 1.0 brings with it expectations of policy changes as well. I am fairly tempted just to continue with current policies. Things like binary stability don't seem to be easy to achieve. And I'm not sure that other practices of mature systems, such as Linux' stable branch vs. development branch, solve important problems for SBCL. But it is a particularly reasonable time to review policies and perhaps improve things. On Fri, Aug 18, 2006 at 10:10:30AM +0100, Christophe Rhodes wrote: > Juho Snellman <js...@ik...> writes: > > > * 1.0.1 released one month later, no guarantees over source / binary > > compatibility with 1.0. But we encourage people releasing > > non-portable internals-using software to maintain > > backwards-compability with 1.0 at least until the release of 1.1, > > expected to happen about a year later. > > This sounds plausible. (In some sense, it's the same-old aggressive > philosophy as the 0.9.x development: if you're using internals, it's > your responsibility to maintain as much backwards-compatibility as you > want.) It's more work for those writing and maintaining libraries > which need internals, which is in some sense where the work needs to > be placed; on the other hand, as someone who helps support some of > those libraries, even I weary somewhat of the compatibility treadmill, > so I'll just say that post-1.0 it would be nice to think about > providing nice exported interfaces for some of the internals. Both Juho's idea and Christophe's idea sound plausible to me. I don't know what's the best way to help the library maintainers with compatibility issues. The ideal of settling nice exported interfaces seems seldom to be realized in practice, and of course constant fiddling is frustrating. I've largely given up on the idea of maintaining .fasl binary compatibility any more than we do already. I could perhaps be convinced it's worth it after all, but right now it seems like too much of a maintenance burden. It's not so easy to test, either, since a fair fraction of things which can fail are obscure. A minimal-patches-for-bad-bugs-only branch running from a particular version --- traditionally relatively-round-numbered- releases like 1.0, 1.1, etc. --- can be useful. However, it might call for a different kind of motivation than most of our developers have. Mostly people choose to work on software that scratches their own itch, and my guess is that few current SBCL developers have systems which would benefit much from such a branch. That doesn't mean that there's no need for it, but if there is little overlap between current developers and people who need it and/or have the energy to work on it, it might be an odd fit to the current administrative structure. Possibly it might even be maintained in a separate repository with separate permissions, committers, and/or administrator. > The other side of this coin is worth examining too, though it's > somewhat harder to get hard data. In the past, there have been > anecdotal reports of people who have rejected SBCL for their use > because of (a) immmaturity and/or (b) instability. Some of them might > even be reading this list, but if they're not, maybe readers know > someone in that situation. It might be interesting to know if the > kind of post-1.0 development policy that Juho proposes would work for > those people, and if not, why not. Indeed, people interested in this should probably speak up. If you're reading sbcl-devel you're probably already qualified to have an opinion:-) and if you have much experience using SBCL or other software in a way which depends on this kind of policy, you're probably more qualified than me... -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Tim B. <tf...@tf...> - 2006-08-21 21:58:49
|
On 21 Aug 2006, at 20:29, William Harold Newman wrote: (Christophe wrote in fact, but before I was subscribed) > I've largely given up on the idea of maintaining .fasl binary > compatibility any more than we do already. I could perhaps be > convinced it's worth it after all, but right now it seems like too > much of a maintenance burden. It's not so easy to test, either, since > a fair fraction of things which can fail are obscure. At least some of the commercial vendors don't do this either. I'm not sure it's a huge deal, because they ship to developers who can recompile (or who are not upgrading), not to end users (who would care if all their binaries broke). --tim |
From: Richard N. <hol...@gm...> - 2006-08-21 19:55:15
|
> Indeed, people interested in this should probably speak up. If you're > reading sbcl-devel you're probably already qualified to have an > opinion:-) and if you have much experience using SBCL or other > software in a way which depends on this kind of policy, you're > probably more qualified than me... Thank you for the invitation, Bill :) As someone who uses SBCL both personally and in the enterprise, and =20 has sponsored work on it, my opinion is probably relevant. I am quite happy with SBCL's current process (monthly releases, =20 incremental development), for a number of reasons. Here are some =20 unorganized thoughts. =95 I don't see much SBCL software distributed as FASLs. Much of the =20 motivation for FASL compatibility seems to be missing, then. =95 Older versions of SBCL are freely available, and are really no less =20= maintained than the latest -- which is to say, you don't lose "vendor =20= support" just because you're running an earlier version. This makes a =20= common practice -- test your upgrades before you do them -- even more =20= reasonable, because you have no race against time. =95 I haven't experienced much gratuitous breakage -- I have two =20 servers, one running 0.9.4 on Linux and one running 0.9.15 on Solaris =20= x86, and they are both using the same source libraries -- indeed, the =20= same libraries I'm using on my 0.9.11 MacBook Pro. I don't recall =20 making any repairs due to internals changes in SBCL. (It's also good =20 practice not to depend on internals anyway!) I think that's a great =20 record. =95 Incremental development along one branch prevents undue spread of =20= developer effort. Multiple branches, unless a product really is =20 feature-complete, also do more harm than good -- at some point you =20 need a feature that's in a later branch, and then you have to do your =20= porting in one go, or backport (which is ridiculous, as it starts =20 creating forks). Would it be good to have people keeping old versions secure and =20 reliable? Sure. Is it likely to happen? Not really, thanks to Bill's =20 point about developers' itches. Is it likely to happen without =20 harming mainline development? Almost certainly not, because funded =20 work on SBCL internals is infrequent. That said, a 1.0 release should carry some kind of burden. I suggest =20 that burden should be a longer feature freeze and thorough =20 documentation* -- it should be a milestone against which conformance, =20= performance, and architecture can be measured, and a moment for =20 taking stock. It should probably also be a "buy the maintainers beer" moment. I =20 don't expect any arguments on that front :) -R * README, INSTALL, MISSING and BUGS, if nothing else -- I'm not =20 expecting magical documentation fairies to appear and start writing =20 hundreds of pages of text, but a "state of the nation" is important.= |
From: Austin H. <au...@pe...> - 2006-08-22 04:23:18
|
> It should probably also be a "buy the maintainers beer" moment. I > don't expect any arguments on that front :) > > -R I support this. I also like the notion of taking a pass at the documentation. I'm not qualified myself, but I'd happily participate in "buy the maintainers beer" portion. How could we organize that? -austin |
From: Nikodemus S. <nik...@ra...> - 2006-08-14 17:06:12
|
Christophe Rhodes <cs...@ca...> writes: > * 1.1.0 released one month later, no guarantees over source / binary > compatibility with 1.0; a branch for 1.0 maintenance set up for > those who want to support 1.0 with bugfixes; I think I would prefer this, plus possibly a Linux style "even minor-versions are stable", kind of thing. That way the normally merry development could continue pretty much as now, and the next "significant" release would be something less intimidating then 2.0... > ? Put another way, what does 1.0 actually mean? (Does it mean that > we have to document all the bits we have lazily not been documenting? > What about bits we don't want to document because they're not > finished?) Rename all internal package SB%FOO instead of SB-FOO, so it is "obvious" they are internal, and move unfinished stuff away from SB-EXT? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Juho S. <js...@ik...> - 2006-08-14 17:59:12
|
Nikodemus Siivola <nik...@ra...> writes: > Christophe Rhodes <cs...@ca...> writes: > > > * 1.1.0 released one month later, no guarantees over source / binary > > compatibility with 1.0; a branch for 1.0 maintenance set up for > > those who want to support 1.0 with bugfixes; > > I think I would prefer this, plus possibly a Linux style "even > minor-versions are stable", kind of thing. > > That way the normally merry development could continue pretty much as > now, and the next "significant" release would be something less > intimidating then 2.0... I don't really like the stable/development split. It's going to discourage people from upgrading their SBCL more often, while we want to do the opposite. One of the great things about monthly time-boxed releases is that regressions are found pretty quickly, since many users will regularly upgrade to the latest release. Branding them as development releases will mean that some of those users will instead stay with the stable release. Likewise we'll probably get a fair amount of stale bug reports (for bugs fixed in 1.1.*) from people still using 1.0. My preference would be for something like: * 1.0.1 released one month later, no guarantees over source / binary compatibility with 1.0. But we encourage people releasing non-portable internals-using software to maintain backwards-compability with 1.0 at least until the release of 1.1, expected to happen about a year later. For example, if we make changes in 1.0.5 which also require changes to Slime, the usual backwards-compability code in Slime will be marked as "Don't delete before SBCL 1.1 release". > > ? Put another way, what does 1.0 actually mean? (Does it mean that > > we have to document all the bits we have lazily not been documenting? > > What about bits we don't want to document because they're not > > finished?) > > Rename all internal package SB%FOO instead of SB-FOO, so it is "obvious" > they are internal, and move unfinished stuff away from SB-EXT? This seems rather pointless. People who need to use internals will do so, regardless of how the package is named, so I don't really see much of a benefit. It'd also be an incredibly disruptive change, breaking any software that refers to the SBCL internals in any way. Which is more than you might think, for example Araneida, clx, cl-sql, kmrcl, McCLIM, and Slime. Which isn't to say that we should completely freeze the internals. But I'd prefer to only break things when the internals really change, not on a whim. -- Juho Snellman |
From: Thiemo S. <th...@ne...> - 2006-08-14 21:09:00
|
Juho Snellman wrote: [snip] > I don't really like the stable/development split. It's going to > discourage people from upgrading their SBCL more often, while we want > to do the opposite. > > One of the great things about monthly time-boxed releases is that > regressions are found pretty quickly, since many users will regularly > upgrade to the latest release. Branding them as development releases > will mean that some of those users will instead stay with the stable > release. Likewise we'll probably get a fair amount of stale bug > reports (for bugs fixed in 1.1.*) from people still using 1.0. > > My preference would be for something like: > > * 1.0.1 released one month later, no guarantees over source / binary > compatibility with 1.0. But we encourage people releasing > non-portable internals-using software to maintain > backwards-compability with 1.0 at least until the release of 1.1, > expected to happen about a year later. > > For example, if we make changes in 1.0.5 which also require changes to > Slime, the usual backwards-compability code in Slime will be marked as > "Don't delete before SBCL 1.1 release". FWIW, this sounds like a reasonable compromise between stability and further development to me. Thiemo |
From: <mar...@gm...> - 2006-08-22 13:53:43
|
> Indeed, people interested in this should probably speak up. If you're > reading sbcl-devel you're probably already qualified to have an > opinion:-) and if you have much experience using SBCL or other > software in a way which depends on this kind of policy, you're > probably more qualified than me... As a sbcl user, although not "power user" I don't think that fasl compatibility is all that important. As someone pointed out, it's easy for a developer to recompile, while user will not care. Branching to stable and develpment port will make things just worse, since there will be more overhead then now. It make sense only for a feature rich project with huge resources which is under heavy redesign to keep and maintain 2 or more branches. I'd more like to see thread under win32 and improved stability with some more docs then separate stable and devel version and fasl level compatibility. Also, internal api shouldn't be changed just for the sake of change, but pretty much as now, when the need arise. Just my 0.02 CSD Regards, Marko |
From: Dave R. <ld...@dr...> - 2006-08-26 14:54:38
|
On Tue, 2006-08-22 at 15:53 +0200, Marko Koci=C4=87 wrote: > As a sbcl user, although not "power user" I don't think that fasl > compatibility is all that important. As someone pointed out, it's easy > for a developer to recompile, while user will not care. Branching to > stable and develpment port will make things just worse, since there > will be more overhead then now. It make sense only for a feature rich > project with huge resources which is under heavy redesign to keep and First, let me say that I don't personally care one way or another on FASL compatibility. I'll just make an observation and everybody can take it for what it is. The observation is simply that it seems to me that FASL compatibility is really an issue if you want to foster a large body of **pre-compiled** software written in SBLC **that is distributed independent of SBCL**. In other words: 1. I don't think developers should care. They understand the problem when it arises and should be comfortable recompiling. As long as there is a heads-up of some sort that breakage will occur when moving to a given release, people can make the decision for themselves at the appropriate time. 2. If you're distributing software as a complete package that includes SBCL, either linked into a single binary with some of the recent techniques to do that or even as a separate image with FASLs loaded, then you shouldn't care. For all intents and purposes, SBCL is a part of the software and the developer can simply recompile and redistribute when they want to release a new version. 3. The only time things break in a way that will be unacceptable is if we expect people to distribute applications independent of a given SBCL to end-users who aren't comfortable managing the issue. Note that this would be a fairly common method on a Linux system with modern package management (yum, apt-get, portage, etc.). Ideally, you'd like to simply reference an SBCL dependency from your application package without forcing it to a specific version. For example, in RPM you'd ideally like to say "sbcl >=3D 0.9.15" or something and leave it at that. Perl, Python, etc., have the same issue, but because they use source for distribution, I think the problems are greatly reduced. This problem is more similar to the libc problems that occurred in the early days of Linux, but which have moderated a great deal of late. Like I said, I don't have a preference one way or another. Generally trying to break as little as possible might foster wider adoption of SBCL (and Lisp in general). I have yet to see a good end-user application written in Lisp and packaged with a modern package management system (not compiled to a single binary including the Lisp image) that just installs and runs without the user having to know that the system is written in Lisp. It's far from impossible, but it just doesn't seem widespread yet. Perl and Python seem to have this nailed, however. -- Dave --=20 Dave Roberts <ld...@dr...> |