> On 25 Jul 2016, at 18:20, Eduard Moraru <[email protected]> wrote: > > Hi, > > On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <[email protected]> wrote: > >> I think I’d be in favor of: >> * Have our xar:format remove the dates >> * Have xar:verify fail if the dates are in the XML (thus our quality build >> will fail if that’s the case) >> * Have the import set the current date if no dates are defined (that’s >> probably the case already, would need to be checked) >> > > A side-effect of this is that, when you upgrade and extension, all the > pages of the extension will be changed and set to the update date as their > last modification dates, right? (i.e. it affects both fresh installs and > upgrades)
Isn’t this what happens now already, i.e. when an existing page is imported the current date is set (unless it’s a backup pack)? If the issue is about the diff, I guess we could have a diff that doesn’t take into account the dates (or a better algorithm could be to not update a page that only has the date metadata modified). > Thinking more about it, it could be problematic for all the pages of an > extension that you upgrade to appear as being modified, even if nothing > changed in them in that particular version. We should definitely not update pages with no changes. > Another minor negative side-effect would also be searching or listing > documents and sorting them by the last update time. Of course, this would > mostly affect admins or users with "show hidden documents" enabled. I we don’t update pages that haven’t been changed we won’t have this problem, right? > However, if you happen to also manage some content pages in your build > (that are not supposed to be hidden), this becomes a nuissance. > > WDYT about the 2 problems? I guess we could always accept them and say that > installs/upgrades are relatively rare and that the impact is minimal (and > similar to an empty save in a document - something that can already be > observed in practice in a document's history - so we don`t introduce > anything new). > > Thanks, > Eduard > > P.S.: Here`s an existing issue more or less related to this topic > http://jira.xwiki.org/browse/XWIKI-7058. Caty reminded me about it. And http://jira.xwiki.org/browse/XWIKI-11764 Thanks -Vincent > * Have AS and Watchlist exclude import / new wiki (already the case) >> >> Thanks >> -Vincent >> >>> On 25 Jul 2016, at 14:08, Eduard Moraru <[email protected]> wrote: >>> >>> Hi, devs, >>> >>> This interesting discussion [1] came up recently on a github commit that >>> lead us to realise that a practice which we have been doing since forever >>> is not documented in our best practices guides and that we also seem to >>> lack consensus on it. >>> >>> It`s about the practice of skipping date field changes from document XML >>> pages when committing them to source control. This includes doc date >>> and contentUpdateDate >>> fields, but also attachment dates. >>> >>> You can see some arguments on the discussion[1], but I also wanted to >>> mention that this practice goes in line with what we do for document >>> versions (which is handled by the xar:format maven plugin goal which we >>> execute every time, before committing XML pages). If we are to update doc >>> dates, then we should also increment doc versions, otherwise it does not >>> make any sense. >>> >>> The idea was, AFAIR, that XWIki`s code pages should not generate any >>> updates in the user`s wiki content, in any way, and that and update of >> the >>> code of a "system"/XWiki page should not show up as an update of *the >>> user's content*, since it would otherwise confuse him. >>> >>> What we are currently missing from xar:format is exactly this: the reset >> of >>> XML page dates to have a clearer and more consistent date for XWiki`s >> code >>> pages. >>> >>> Your input is appreciated and the result of this discussion would be the >>> update of our Development Practices [2] and Application Development Best >>> Practices [3] pages. >>> >>> Thanks, >>> Eduard >>> >>> ---------- >>> [1] >>> >> https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb22286273bffdea5530#commitcomment-18375907 >>> [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices >>> [3] >>> >> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
