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

Sorry, I understand that part. And I do want to turn DrScheme
into an OS and Planet into a regular "software update" process
so you can get the latest pieces when they are released.

I just didnt understand the scenario that was dealt with.


On Jun 9, 2009, at 9:43 AM, Robby Findler wrote:

> Well, if you look at the larger picture of a community-wide
> synchronized release of everything that is currently in planet, that
> is clearly untenable. So there is some value in letting things move
> independently. Another thing to compare to is OS releases. Perhaps we
> should be spending more manpower on planet and everything outside of
> mzscheme and a few core libraries should move there. Then, a major
> release corresponds to picking a set of version numbers from planet
> and packaging them into a single distributable.
>
> Robby
>
> On Tue, Jun 9, 2009 at 8:39 AM, Matthias  
> Felleisen<matthias at ccs.neu.edu> wrote:
>>
>> Thanks. I understand that but I find the probability of such
>> scenarios low. Perhaps it's a lack of experience with planet
>> libraries.
>>
>> Eli just told me that SU isn't a part of the release yet, so my
>> assumptions were wrong, too.
>>
>> I think it should be a part of the release and I have told Eli so.
>>
>>
>>
>>
>>
>> On Jun 9, 2009, at 9:36 AM, Robby Findler wrote:
>>
>>> 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
>>>>>>
>>>>
>>>>
>>
>>