One thing that would have been helpful would have been the ability to run the upgrade1.1 and upgrade1.2 tasks on code in plugins. I try to write my most extensive code in plugins, even if it's only for our own internal use, and as a result I had to manually make a lot of changes.
Other than that, I have no complaints. The upgrade documents for each version were very helpful. David On Thu, Dec 18, 2008 at 6:52 PM, Jonathan Wage <[email protected]> wrote: > Very good to hear that you were able to upgrade without too much trouble. > Makes me feel good that we were able to move forward without making too many > huge BC changes. > > Thanks, Jon > > On Thu, Dec 18, 2008 at 8:26 PM, David Brewer <[email protected]> > wrote: >> >> The revision history on where exactly the tag came from is nice... but >> the export approach sounds a lot easier on the person making the tag. >> And, if external dependencies move around for any reason, you don't >> risk winding up with code missing because someone's repository moved >> or was shut down. Sounds like a good idea! >> >> By the way, I've been upgrading projects from symfony 1.0 and an >> ancient version of doctrine (0.9 at a specific revision) to symfony >> 1.2 and Doctrine 1.0. I had some bumpy spots toward the beginning, >> but I'm almost done now and it's looking like smooth sailing from here >> on out. I was concerned that the Doctrine upgrade was going to be >> painful, but actually it was probably the easiest part (after I >> extracted my reliance on some specific features of the old codebase, >> which were keeping me there long after I should have been). >> >> Thanks to everyone involved -- I am very excited about getting up to >> date on these two great projects again. Next step: weaning myself >> from the compatibility layer. :-) >> >> David >> >> On Thu, Dec 18, 2008 at 6:18 PM, Jonathan Wage <[email protected]> wrote: >> > We were discussion this today actually and you are right, all the >> > externals >> > need to be frozen to a revision or tag. The other solution is to instead >> > of >> > copying the branch to create the tag, export the branch and then import >> > it >> > in to the tag. That way it is completely frozen. >> > >> > - Jon >> > >> > On Thu, Dec 18, 2008 at 7:58 PM, David Brewer <[email protected]> >> > wrote: >> >> >> >> I've switched to installing symfony using svn:externals references to >> >> tags. This is very convenient as it allows me to run multiple >> >> versions of symfony on a single server. I just today noticed >> >> something which concerns me a little bit, though. In at least once >> >> case, a directory under a release tag is coming from an external >> >> reference to a branch rather than a tag. This means that the >> >> functionality of the tagged release will change over time as bugfixes >> >> get made to the change. >> >> >> >> The specific example is the Doctrine library, part of the >> >> sfDoctrinePlugin and found here: >> >> >> >> >> >> >> >> http://trac.symfony-project.org/browser/tags/RELEASE_1_2_1/lib/plugins/sfDoctrinePlugin/lib/vendor >> >> >> >> The external reference is to >> >> http://svn.doctrine-project.org/branches/1.0/lib/. I just saw a >> >> couple of changes roll in there which alerted me to the situation. >> >> >> >> Is there any chance that we can change this so that any externals in a >> >> tag are also pointing to a tag? Theoretically at least, you should be >> >> able to rely on a tagged release not changing... >> >> >> >> David Brewer >> >> >> >> >> > >> > >> > >> > -- >> > Jonathan H. Wage >> > Open Source Software Developer & Evangelist >> > http://www.jwage.com >> > http://www.doctrine-project.org >> > http://www.symfony-project.org >> > >> > > >> > >> >> > > > > -- > Jonathan H. Wage > Open Source Software Developer & Evangelist > http://www.jwage.com > http://www.doctrine-project.org > http://www.symfony-project.org > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
