Hi Wagtail people,
I would in hindsight warn against this module refactor, even though it's too late (and yes I really agree, it's too late now).
The main problem (from reading release notes), is that no one seems to have addressed the community effort needed to carry out this refactor. The motivation seems to be about module path aesthetics.. not exactly a benefit.
The release notes are not very clear:
While this will require some up-front work to upgrade existing Wagtail sites, we believe that this will be a long-term improvement to the developer experience, improving readability of code and reducing errors.
Developer experience points towards "improving readability"? And
then the "reducing errors", what's that? If it's about spelling
errors, then it's because the readability is improved? So then the
same point is made 3 times :P
I can understand why someone would do this kind of refactor:
There has already been a tendency towards refactors based on
aesthetics in Django -- so there is a common practice that
disrupting people's projects with these sort of changes is okay.
I'm used to modules being called `wagtail.wagtailcore`, I think it's fine, I'm not bothered by it. Instead of being encouraged by an update, I now feel discouraged, because it will mean extra work with no benefit.. I will probably do the upgrade anyways, because I know that not keeping up2date also has high costs.
The more elaborate our compatibility layer is, the more chance there is for things to break in unexpected and subtle ways.
Then don't do a module refactor :) If arguing against having a compatibility layer that would be helpful to people is a logic that's not about a) value creation or b) problem solving -- but is about c) a (some what hypothetical) complexity analysis of a solution to an unnecessary problem.... then we need a much stronger argument for the module path refactor in the first place!
The fall-out for users is huge (let's say 1,000 deployments * 1h avg upgrade work?), and Wagtail community will be kept busy with ImportError support questions for some time, I would presume.
Then we also get problems with all reusable application. They will invent their own compatibility layers, or they will have to support odd breakages that they didn't anticipate (for instance if their test coverage is low). And a few will never adapt and be left abandoned.
Fixing this up and releasing new versions of all the reusable
apps? Let's just say another 1,000 hours of work, if it's just
left for the community to fiddle with (although a small, efficient
task force visiting all the reusable Wagtail apps to fix them up
for Wagtail 2.0 would be much more efficient).
I hope for the future of Wagtail that similar refactors will be
considered a bit more carefully, and that's my only point!
Still your fan and contributor,
Ben
Cheers, - Matt -- You received this message because you are subscribed to the Google Groups "Wagtail support" group. To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+unsubscribe@googlegroups.com. To post to this group, send email to wag...@googlegroups.com. Visit this group at https://groups.google.com/group/wagtail. To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/357496df-ec48-4d40-b7d8-c21cba815fc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Wagtail support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wagtail/m1ETi2PIwxw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wagtail+unsubscribe@googlegroups.com.
To post to this group, send email to wag...@googlegroups.com.
Visit this group at https://groups.google.com/group/wagtail.
To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/68c6f7dd-3be0-057f-f1c3-7ae51973ab90%40gmail.com.