#12937 closed task (duplicate)
provide migration path for upcoming jinja2 changes
| Reported by: | Owned by: | Ryan J Ollos | |
|---|---|---|---|
| Priority: | normal | Component: | DateFieldPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 1.2 |
Description
I've been experimenting with the jinja2 branch which is running a 1.2 dev revision, that has all of its templates converted to the new templating engine.
As far as this date field plugin is concerned, I've been able to do some migration and can provide code here in this ticket.
HOWEVER, it feels like this plugin should not be encouraged to be used going forward, in favor of the new native time field type? If so, it would be nice if there were streamlined migration instructions on converting existing deployments from this custom field type into the new native type.
Any thoughts on direction here?
Attachments (0)
Change History (3)
comment:1 follow-up: 3 Changed 8 years ago by
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 Changed 8 years ago by
I am in support of changing the title of this ticket to not refer to jinja2 and instead focus on documenting the migration steps:
- sql statements for:
- ticket field template tables?
- workflows?
- custom field tables?
- removal of plugin from trac.ini
- removal of plugin via package manager (pip uninstall, rm -rf site-packages/datefield)
I would certainly do this but do not feel nearly as qualified as others who have seen the native time field.
I will revisit after the jinja2 branch is rebased onto 1.3.
Replying to mark.clifton@…:
Yes, the new time field should be used in 1.2 and later. There's a warning on the DateFieldPlugin page about it's deprecated status. See also trac:wiki:1.1/TracUpgrade#ObsoletePlugins.
Having instructions and a migration script would be valuable. That's the topic of #12937. Feel free to attach any suggestions to that ticket.