Re: [xwiki-devs] [Discussion] Committing date changes on document XML files

I'm +1 for not committing date changes and it would be helpful to ignore them at some point, since I need all the time to edit files to commit in order to revert date changes. Thanks, Alex On Mon, Jul 25, 2016 at 10:40 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com > Le 25 juil. 2016 18:31, "Vincent Massol" <vincent(a)massol.net> a écrit : >> >> >>> On 25 Jul 2016, at 18:20, Eduard Moraru <enygma2002(a)gmail.com>>> >>> Hi, >>> >>> On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <vincent(a)massol.net> >>> >>>> 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)? > > Yes EM does not take into account plumbing stuff like date and version. > >> >> 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). > > It's already the case... > >> >>> 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 <enygma2002(a)gmail.com> >>>>> >>>>> 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/1938dd18e1d25b8c03e4cb222862… >>>>> [2] > http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices >>>>> [3] >>>>> >>>> > > http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… >>>>> _______________________________________________ >>>>> devs mailing list >>>>> devs(a)xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs