Xliff

I think migrations should be their own thing, especially since migrations are done at the Model level, not the collection one. Collection versioning is a great idea, though!

Maybe best explained, Migrations are an operation between two versions of the same model. So how would that best work? Maybe have something that encapsulates models like a collection, but...

Actually, that's not a bad idea. However I was hoping to use methods for individual fields. In that case, field level conversions could use another mechanism. Try this: ```perl6 #...

@FCO: This is why I had the %!conversions attribute. So for something like this situation, you'd have ```perl6 submethod BUILD { %!conversions = -> { $new_model.b = $old_model.a }; }...

Yes. That;'s not bad. It accomplishes the basics. However I would prefer if we did migration as a ClassHOW so that we can split complex operations up into encapsulated (self-contained)...

The only problem that I see is that the model would need to contain interim attributes until the migration is complete. From I am reading (please pardon me if my...

> But what about the code to handle the 2 versions of the database in the middle? That would only be a factor _during_ the migration. During this time, I...

> In my head, after that migration is done, you would commit a new version of your code removing the migration code... Ah. OK. In _my_ head ( :smile: )...

@codesections - I've already had this discussion with ugexe. We both have agreed that this issue is best settled via CURI

@ugexe - I disagree. RAKUCO_PRECOMPILATION_PROGRESS is _not sufficient_. It can't be. It too does not know what the distributor wants to communicate to the user at install time. If this...