Phase 5 - Better structure ?

[KevinJump]

So I am considering a bit of a project tidy, to clean up and hopefully make it easier for people to see where things go.

At the moment the migrators are all just dumped into the "Migrators" folder of the main project, not much in the way of structure to it.

My initial idea is to pull out the 'none' core migrators into their own project, so they are separate from the core workings of the migration ?

It would be nice to say to people - here is where migrators go, Implement this interface and you are sorted, put your models here and it will all be taken care of.

e.g :

(its called converters here, because i didn't want to get bogged down with namespace clashes, if we go this way might change)

• this is mostly doable, but Archetype is very much mangled into the core at the moment ,it it probably shouldn't be

In doing this - i found sorting the migrators into folders for the migrator + its models made it look much cleaner and easier to navigate

So that was pleasing.

I am not 100% sold on the separate project thing,

• it does move them out nicely, so people can see quickly that they need to add a migrator to this other project.
• will it discourage people tweaking the migration context, ? I mean sometimes people have to do that, but if you are working separate you might not.

but its quite a large namespace change, its certainly breaking for any custom code people might have attached to this, so i don't want to break things just for neatness. when just a folder nested might do that anyway ?

Pinging anyone who's PRed migrations in the last few months :
@grey-muir @Wiggee11 @ryan-woodruff @Hendy @michaelchart @marcemarc @leekelleher @jhenkes @skttl @peterkeating @bielu

[bielu]

@KevinJump I think it is good idea, and package is still not officially released so better to break it now than wait for another major release where adoption would much worst of breaking changes, as people would expect that we will try to avoid big breaking changes :)

[michaelchart]

Yes, I agree it's a good idea. Since uSync Migrations isn't something that lives long in a project, the effect of breaking changes is more limited. At least how we're using it, it's generally an "install, migrate, uninstall" with a few steps in between!

[marcemarc]

I think the separate project does make it clearer where you can contribute things,(at the moment we never install it, just add a fork of the repo into the solution so that it's easy to make changes and contribute back / remove at the end of the migration). When I've explained it to people, I've had to dig down to find a converter, so surfacing it in a separate project does give off the 'it's ok to do your stuff here;' vibe... Having the models with the migrator in the same subfolder also makes it clearer what is involved in a migrator.

Would it make it easier in the future.. then to have a set of converters grouped by their usefulness? eg V7 converters might include archetype etc, but in the future people will still want to migrate things as other property editors become obsolete.. and use this same technique/approach... ?

[KevinJump]

I think so @marcemarc - but at the moment the road block has been how tightly some things like archetype have been integrated,
for example, it has these configurators that are injected into helper classes which in hindsight i am not sure they need as the context could probably do the job.

but that means splitting is a bigger than 'spare time' job, so I've done a scaled back cleanup for now in #224 - i will revisit. but it turned into a project blocker for me - so quick and dirty step 1.