+1 P2 Thanks, Caty
On Sat, Jan 13, 2018 at 4:16 PM, Denis Gervalle <[email protected]> wrote: > 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 >
