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<matth...@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<matth...@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
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
