Hi Katherine, IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year.
Regards, Brenden On 18 December 2012 11:40, Katherine Moss <[email protected]> wrote: > Interesting. I think I guessed IronRuby since that plugs right into > .NET, you know? By the way, is that even still being developed? It > doesn’t seem that IronPython is; the last update for it is version 2.73, > though C Python is all the way at 3.0. What’s with that, I wonder? Maybe > all of the members of those projects left or something? **** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ben Scott > *Sent:* Monday, December 17, 2012 8:38 PM > *To:* ozDotNet > *Subject:* Re: Managing databases**** > > ** ** > > Just plain Ruby. I think I used RubyInstaller for Windows - > http://rubyinstaller.org/ > > **** > > On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss < > [email protected]> wrote:**** > > Is that written in IronRuby, by any chance?**** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ben Scott > *Sent:* Monday, December 17, 2012 8:29 PM > *To:* ozDotNet > *Subject:* Re: Managing data**** > > **** > > I have a similar system but I have a simple ruby script that applies > migration scripts. I can run it against development databases and when I'm > deploying a new version of the system I just run it against the production > database. It includes a bootstrap migration to create the schema version > table, and if the first migration is a dump of the existing schema and you > insert the migration record on production you can create development > databases totally in script. I've open sourced the script at > https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations > > **** > > On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear <[email protected]> > wrote:**** > > I guess this is an age old problem, managing database changes such that > they respect applications dependent on them. We are bolting more > applications to a couple of sql databases so the management exercise is > becoming more complex, risky and expensive to maintain.**** > > **** > > Currently we have a database version number, use schema naming for > application specific views and procedures and have a folder of each change > in sequential order that has to be applied to production.**** > > **** > > Over the holiday break I thought I might research how we can improve our > approach. What systems have you or your organisations adopted to keep it > all under control , and are they successful? **** > > **** > > **** > > -- > > ----------------------------------------------------------------------------- > Stuart Kinnear > Mobile: 040 704 5686. Office: 03 9589 6502 > > SK Pro-Active! Pty Ltd > acn. 81 072 778 262 > PO Box 6117 Cromer, Vic 3193. Australia > > Business software developers. > SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. > > ----------------------------------------------------------------------------- > **** > > **** > > ** ** >
