Le 25 juil. 2016 18:31, "Vincent Massol" <[email protected]> a écrit : > > > > 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)?
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 <[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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
