Same as Thomas. -- Denis Gervalle SOFTEC sa - CEO
Le 12 janv. 2018 à 16:04 +0100, Thomas Mortagne <[email protected]>, a écrit : > On Fri, Jan 12, 2018 at 1:50 PM, Eduard Moraru <[email protected]> wrote: > > Hi devs, > > > > These are the current code style rules for committed XML wiki pages: > > http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle > > > > = Proposal 1 = > > > > I was personally not aware we had documented these practices that we had > > been applying since forever. It's good that we have them, but there seems > > to be no mention about committing changes for the "creationDate", "date" > > and "contentUpdateDate" fields. > > > > Part of the committers (including myself) are applying the old practice of > > omitting changes to the date fields when committing a change to an XML wiki > > page. However, since this practice is not written and agreed upon, its > > usage is not consistent. > > > > So, the proposal is to include the rule of not committing changes on the > > date fields of XML wiki pages. > > > > The rationale, AFAIR, includes: > > * After an upgrade, users should not see "ghost" modifications in their > > wiki (e.g. when sorting by date in the Page Index). This affects even more > > manual imports with the "as backup" option enabled. > > * On release, any date changes of a default translation XML page will > > produce N other XML page changes, for each translation of the modified page > > (due to the way l10n exports the translations based on the latest version > > of the default language of that page). > > * others? > > > > = Proposal 2 = > > > > Now, building on this, I would like to make a second proposal (which I > > don't believe deserves a separate thread): > > 1) Let's remove all date fields from committed XML wiki pages in our source > > repository > > 2) Let's make sure that the XAR import properly handles empty or missing > > date fields and falls back on the current date > > XAR input filter supports both but I don't see the point in having an > empty date, better remove it. > > > 3) Let's update the xar:format goal to remove the date fields > > (configurable, since it could they might still be needed by some content > > projects, etc.) > > 4) Let's make the build fail (xar:verify) if the XML wiki pages contain > > date fields (again configurable, as above) > > > > Note: All the above still depend on the first proposal of not committing > > date changes to XML files (which will be simplified by point 3) above). > > > > The rationale for this is that we have always wanted to fix our "dates > > problem", since after installation, the wiki is populated with pages > > created in 2009, which is extremely odd to users that have just installed > > XWiki. This second proposal sounds to me like a solution for that. > > > > WDYT? > > > > Thanks, > > Eduard > > - 1 for proposal 1 alone > +1 with proposal 2 > > I don't care too much about update date vs not update date but we > should not have to do any manual cleaning when exporting a page. So in > short I'm against anything not handled by xar:format. > > (by the way > http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle > is not fully up to date since what is indicated for defaultLanguage is > not true in case of translations) > > -- > Thomas Mortagne
