Mailing-List: contact embperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Sender: root@dev.nilspace.com
Message-ID: <3EFA04F6.ED8A1B79@nilspace.com>
Date: Wed, 25 Jun 2003 15:24:22 -0500
From: Neil Gunton <neil@nilspace.com>
MIME-Version: 1.0
To: Ed Grimm <eg@raytheon.com>
CC: embperl <embperl@perl.apache.org>
Subject: Re: Testing 2.x with production 1.x code
References: <3EF9DC05.D4C594EB@nilspace.com> <3EF9E21F.B692C237@nilspace.com>
 <Pine.GSO.4.53.0306251928260.23661@dsblade00>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Grimm wrote:
> 
> I haven't looked at the transition yet, but your worrying example
> doesn't seem too worying to me.
> 
> $req_rec = $req->apache_req()

This actually doesn't work. The apache_req() method is only available
under the 2.x API. So you'd need some sort of switch to decide which
call to make (if I'm missing something obvious here then I apologize in
advance!). This is the kind of thing that I am talking about; sure, I
could try to spend the time hacking my code around to work with both 1.x
and 2.x, but I just thought that it would make the testing of 2.x go
*much* faster the easier it was for people like me to just swap 1.x and
2.x in and out to test the latest beta. I know that I for one have shied
away from fully testing 2.x because of the large amount of existing code
that breaks with it... I can't be the only one in this situation. It's
been a long time since 2.0b8 came out, and I have a feeling this is
because (in part) people with large existing websites find it hard to
test without breaking the code, and so end up avoiding it. It's a
chicken and egg situation - 2.0 won't become truly stable until people
like us test it on our large existing codebase, but on the other hand
people like us with large existing codebases are probably also very busy
and loathe to change that codebase to work with a buggy new version,
while also breaking compatibility with Embperl 1.x. Sure, I could try
hacking my stuff to make it work with both, but I just wanted to find
out from Gerald what he thinks of the idea and how hard it would be to
just build it in. It might be time well invested on his part, if it
means that people like me can just take 2.0bx and swap it in and out,
testing and reporting bugs, with minimum intrusiveness on the existing
code.

> 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.
> 
> Ed
> 
> 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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org