I can release a 1.4, probably, though to make sure it really works means going through... let's see... probably at least a half dozen setup-plt runs including rebuild of Scribble docs and search index. (One to remove my current build of the package, one to add version 1.3 and duplicate the bug, one with the fix to make sure it works, one to remove that, one to add and test it from the built .plt package instead of the development link, one to remove that, and one to put my normal version back. That's seven.) If we run into other dependencies on old versions of my code, I may have to repeat this process for major versions 2 and 3 of cce/scheme.plt as well, plus old versions of fasttest and dracula.
And while I am doing this, I can't do anything else with DrScheme because the code won't load (I need Dracula, which needs all of these packages). I can't even run a different version of DrScheme, because they all share one set of development links. I really don't want to have to maintain outdated packages this way. I would much rather deprecate old versions, and leave it up to other authors to keep their code up to date too by updating old versions as needed. This way no one would have to update more than one version of each package when things go out of date. If we have some pressing need for (planet cce/scheme:1) to work that is greater than other obsolete dependencies, I can release a fixed version 1.4, but it would just be a band-aid on the general issue of obsolete planet/PLT dependencies. If this is just one instance among many, I think it is up to the ssax/sxml author(s) to upgrade to a newer version of my package. I do wish there were a way to specify an upper limit on the version number with which a package is compatible, just like we have a lower limit. That way users would get an error message stating clearly that the cce/scheme:1:3 dependency was broken in PLT 4.1.5, instead of an error about uncertified contexts. I could remove cce/scheme:1:3 from the server (make it unavailable), but that breaks code for users still in 4.1.4 or earlier who can use it without problem. Right now all I can do is leave the current error message and explain it to users when it comes up. --Carl On Thu, Mar 19, 2009 at 2:21 PM, Robby Findler <[email protected]> wrote: > Carl: is it possible to release 1.4 of your package that just deals > with this bug? Or is there no fix to the bug that doesn't also break > the interface somehow? > > Robby > > On Thu, Mar 19, 2009 at 1:19 PM, Doug Williams > <[email protected]> wrote: >> It seems to be one of the sxml or ssax packages that eventually leads to the >> error message. They lead to many packages being downloaded. >> >> On Thu, Mar 19, 2009 at 12:14 PM, Carl Eastlund <[email protected]> >> wrote: >>> >>> Oh, you're using an old version of my package. I don't know what you >>> have that depends on cce/scheme:1:3, but please notify the appropriate >>> author to upgrade their dependency to cce/scheme:4:1. The old version >>> will definitely run into this bug. >>> >>> --Carl >>> >>> On Thu, Mar 19, 2009 at 2:10 PM, Carl Eastlund <[email protected]> >>> wrote: >>> > Oh, hey, that is my package. Sorry, I saw "williams" in the path and >>> > leapt to a conclusion without noticing it wasn't the package owner >>> > name. I'll look into it. >>> > >>> > --Carl >>> > >>> > On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams >>> > <[email protected]> wrote: >>> >> Carl, it looks like the error came from your scheme.plt package. I'm >>> >> not >>> >> sophisticated enough yet to need sandboxes - particularly in a scribble >>> >> manual. >>> >> >>> >> Doug _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
