[plt-dev] Re: Pre-Release Checklist for v4.1.5, second call

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
<robby at eecs.northwestern.edu> 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
> <m.douglas.williams at gmail.com> 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 <carl.eastlund at gmail.com>
>> 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 <carl.eastlund at gmail.com>
>>> 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
>>> > <m.douglas.williams at gmail.com> 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