perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Grimm <>
Subject Re: Testing 2.x with production 1.x code
Date Wed, 25 Jun 2003 19:34:19 GMT
I haven't looked at the transition yet, but your worrying example
doesn't seem too worying to me.

$req_rec = $req->apache_req()

I suspect there are three kinds of changes:

1. Changes that work in both.
2. Changes (like the above) which can be made compatible fairly easily,
by people other than Gerald.
3. Changes which would need more effort to implement a compatability
mode to handle.

I'd suggest we probably want to handle as much of the second case as we
can, because I feel Gerald's time is at a premium.  After we've narrowed
the incompatabilities we cannot handle to a minimal set, submit our
compatability mode settings to him for review, and list the others we
know about that we can't handle.

Disclaimer: I don't have time to assist with this much yet.


On Wed, 25 Jun 2003, Neil Gunton wrote:

> Here's an idea: There seem to be two kinds of changes that have to be
> made to existing 1.x code in order to transition to 2.x. The first
> kind are changes which would still work under 1.x (for example putting
> brackets around the expression in [$ foreach $], or making [+ do { }
> +] for expressions which had more than one statement). Obviously those
> are changes that I am ok with making, because although they are
> necessary for 2.x, they won't break my site under 1.x. The other kind
> of change is the more worrying one - where I have to change the code
> in a way that breaks 1.x, e.g. the way I reference certain objects or
> methods. To take just one example, in my current site I call
> $req_rec->update_mtime() to set the modification time for the page,
> whereas in 2.x you have to have something like
> $req->apache_req->update_mtime(). This is different enough that it's
> worrying to go through all your code changing it, knowing that you'll
> just have to roll back if 2.x breaks for some reason.
> So here's the question for Gerald: How hard would it be to include
> "compatibility" objects and methods so that code will work under both
> 1.x and 2.x? So I could count on, for example, $req_rec being there in
> either version? I have no idea how many other little instances of this
> there would be, but it's just an idea. It would certainly make testing
> 2.x much easier for people like me who already have large "production"
> installations of Embperl and need to test 2.x. without converting all
> their code immediately. I think anyone like me would be a little
> cautious about changing all their code to test 2.x, and then having to
> either change it all back again to go back to 1.x, or else develop
> some kind of complex merge that would quickly get out of date as new
> development is done.
> Just an idea, let me know if it's totally impractical...
> Thanks again
> -Neil
> Neil Gunton wrote:
>> Hi, I am finally having the time to get into trying out the 2.0b9 to
>> see if I can transition my existing websites. However I am having a
>> problem with the fact that there are so many little things that are
>> different between 1.x and 2.x (different objects to call, for example
>> the $req_rec object apparently doesn't work any more). If I change my
>> code to work with 2.x then it won't work with 1.x any longer - but I
>> don't want to commit all my code to 2.x until I am sure it works, and
>> I don't want to have to maintain two versions of my code (there is a
>> lot of it on the crazyguyonabike website, some 393 files at present,
>> some quite large).  During the time I am testing 2.0b9 I will still
>> have to be making updates and fixes to my production sites, I can't
>> freeze development until 2.0 is ready - it is uncertain when 2.0 will
>> be stable enough for production use. I realize that it will only get
>> there if we all test it out under real conditions, which I want to
>> do. So any advice on how to fully test out 2.0b9 on existing
>> production code without having to commit to 2.x prematurely, or else
>> maintain two separate versions of my code? Sorry if this is a dumb
>> question.
>> Thanks,
>> -Neil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message