I know that Franck Cuny as been forwarding my status reports, but when ever I can I will post them to the list. If you feel like reading any other stuff related to my project, you can find all my posts in http://log.gnusosa.net/code/gsoc Suggestions, questions and comments are welcomed. Thanks. :) # The format continues as last time. You can access the HTML # formatted version of this text going to http://log.gnusosa.net/code/gsoc/status-report-3 Well on week #3, I wasn't able to do much work due to the schoolwork load of this month. Just like every other participant of GSoC, I dedicated half of my days to studying and writing to prepare for my finals. Aside from that, I could review the ideas related to the upgrade/update process on the project. I met with my mentors to sync- up with current events related to that week work, but since not much work had been done on the repo, it seemed unnecessary. What I worked on week #2 For week #3, most of my time was invested in investigating which upgrade/update process would be better for the project. It's stipulated has the work for week #4, but before that I did the research based on Catalyst::Scripts*, catalyst.pl, Catalyst::Helper. So what my mentors and me decided, was to mimic the scripts organization from Catalyst. From catatyst.pl, one feature did made me think of the possibility of implementing such in our script bin/ dancer. That feature works around writing new updated files with the ending .new, that way the user can still have its old files, and chose which solution is best, or start hacking the migration of such deprecated functions, method, file into a solution the user might find best fit for his application. Dancer's developers and contributors write a lot of code that works around with what we call, "automagically". Which is what I was looking for my project, an automatic yet not so stressful way to upgrade/ update outdated files, and that works for almost every situation. That way is a magical and automatic solution. What I decided to go for as of this moment of the project, is to use or write an algorithm that would parse each file in the lib, the config file, and the environments files, to look for outdated subs and functions. So this is where the upgrade/update process stands as of right now. So for a start we decided, that I could use a module, and if that module seems solid and lean, we might stick to it. But since Dancer depends on very basic modules, I don't want to add more to this well thought line of decisions of what works and what doesn't for Dancer. However, sawyer suggested that I could write the portion that we need for the upgrade/ update process. So if you know of such module, or you have worked on string-to-string comparison with a solid module, please let me know. Suggestions are welcome, and they really help. :) What's next? For week #4, the following must be accomplished: Write the upgrade/update methods. Write the tests for the upgrade/updates methods. This means I will be back on writing code to Dancer::Script and add a quick tweak to bin/dancer script. Also, to work again with tests, is what keeps me more motivated, I really like the whole test then write code as you go workflow, and I would like to try it more after GSoC is over. But for that I will need a solid base with testing. So more code, more tests, more coffee. :) So to every mentor and participant, have a great week #4, and to everybody still working they way through finals, best of luck and give yourself the time to relax. Cheers.