[plt-dev] Re: [plt-scheme] SchemeUnit confusion

I think the worry goes something like this:

a) I use the plt web server and scheme unit (to pick two arbitrary
parts of the distribution, really this could be X and Y iiuc).
b) a new release comes out that has a bugfix in the web server that I need
c) the new release also comes with backwards incompatibilities to
schemeunit that break my code that I don't have time at the moment to
fix.

What to do? Well, if I had used schemeunit from planet, I could
(probably) upgrade the webserver only, without upgrading schemeunit.

Robby

On Tue, Jun 9, 2009 at 8:33 AM, Matthias Felleisen<matthias at ccs.neu.edu> wrote:
>
> Then I don't understand the exchange either. People who use an actual
> release (as opposed to the svn head) have a stable release of SU. When
> the next release comes out, they get a pre-compiled bundle, ready to
> install.
>
> Sorry for being dense -- Matthias
>
>
>
>
>
>
> On Jun 9, 2009, at 9:31 AM, Robby Findler wrote:
>
>> I think the concern is for code that is being written by people who
>> aren't working in our SVN repository.
>>
>> Robby
>>
>> On Tue, Jun 9, 2009 at 8:21 AM, Matthias Felleisen<matthias at ccs.neu.edu>
>> wrote:
>>>
>>> We routinely update collections in the core code base and most of the
>>> time,
>>> it suffices to run setup on the new collection or a few others.
>>> (Personally
>>> I often update my code base from scratch once a day.)
>>>
>>> I think it would be great if we got into this mode for SU, too. --
>>> Matthias
>>>
>>>
>>>
>>>
>>>
>>> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote:
>>>
>>>> From an app developer's point of view, I think Noel's reasoning is this:
>>>>
>>>> All of PLT is bundled together under one big version number. If you
>>>> upgrade the core, you upgrade all the satellite libraries as well. This
>>>> has
>>>> three drawbacks:
>>>>
>>>>  - if you want to upgrade to a newer version of PLT for an improvement
>>>> in
>>>> one library, you may have to deal with potential backwards-incompatible
>>>> changes in other libraries at the same time;
>>>>
>>>>  - compiling all of PLT can be slow;
>>>>
>>>>  - other software you have developed may still use older versions of
>>>> PLT.
>>>>
>>>> PLaneT offers a little more flexibility: to a certain degree you can
>>>> choose to upgrade one dependency independently of the rest.
>>>>
>>>> In other words, if Noel makes a change to Schemeunit, and a developer is
>>>> requiring it from the core, he/she will have to update all of PLT at the
>>>> same time, which might take a while and make upgrading difficult. If,
>>>> however, the developer is requiring Schemeunit from PLaneT, they should
>>>> hopefully be able to just upgrade that one library and leave everything
>>>> else
>>>> as-is.
>>>>
>>>> Cheers,
>>>>
>>>> -- Dave
>>>>
>>>>> Noel, I don't understand this response at all. Could you elaborate? In
>>>>> the past we have deprecated planet package when we moved code into the
>>>>> core.
>>>>> -- Matthias
>>>>>
>>>>>> Dependency management. We've been bitten by changes in the web server
>>>>>> stopping us upgrading PLT to get bug fixes in other areas. Now
>>>>>> SchemeUnit isn't as likely to change as the web server, but why make
>>>>>> the dependency if you can avoid it? (This only applies if you aren't
>>>>>> developing core code. If you are, use the core version.)
>>>>>>
>>>>>> N.
>>>>>>
>>>>>>> Why recommend the planet version over the core version?
>>>>>>>
>>>>>>> Robby
>>>>>
>>>> _________________________________________________
>>>>  For list-related administrative tasks:
>>>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>>
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>>
>
>