25 Jul
2016
25 Jul
'16
6:31 p.m.
On 25 Jul 2016, at 18:20, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
Hi,
On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <vincent(a)massol.net> wrote:
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).
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) 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On 25 Jul 2016, at 14:08, Eduard Moraru
<enygma2002(a)gmail.com> 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/1938dd18e1d25b8c03e4cb222862…
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