Conversation
|
Ah, of course, this breaking change cannot be backported, at least in tests… I'll see it later, then. |
WTForm backward compatibility needs that
| Flask-Talisman>=0.8,<1 | ||
| Flask-WTF>=0.14.3,<2 | ||
| WTForms>=2.3.1,<2.4 | ||
| WTForms>=2.3.1,<3.1 |
| ) | ||
|
|
||
| try: | ||
| # Compat for WTForms <= 2.3.3 |
There was a problem hiding this comment.
Why should we keep backwards compatibility?
There was a problem hiding this comment.
That's exactly my question. My experience showed me that jumping early on the "new backward incompatible release" train can be really annoying. So I tend to prefer solutions that introduce a backward compatibility layer, but I think this is not possible here, due to the default change for string values.
There was a problem hiding this comment.
My experience showed me that jumping early on the "new backward incompatible release" train can be really annoying.
Ah, that seems bad indeed. Could you explain why?
|
can this be merged ? I kind of need that for the downstream nixos package. |
|
Okay, let's do that for now, and drop it later on :-) |
|
thanks ! |
* Support WTForms 3 * default value to None for WTForm backward compatibility * switch back to empty string as default WTForm backward compatibility needs that * format
3 participants
This bring the latest version, but some breaking changes are introduced.
Especially, StringField now default to
Noneinstead of'', so I changed the tests, without knowing the real impact.@zorun do you have an idea of a real use case where it can break? All columns are nullable, as far as I know, but I want to be extra sure.