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 >