[xwiki-devs] [Discussion] Committing date changes on document XML files
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/1938dd18e1d25b8c03e4cb2228627... [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3] http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
+1 to not commit date field changes. I would even modify the XAR format mojo to remove these date fields. The XAR plugin could set them when the XAR is build (based on the date when the XML files were last modified or based on the current date, when the XAR is created). In other words, I don't think these date fields should be versioned (no need to push them to SCM). Thanks, Marius On Mon, Jul 25, 2016 at 3:08 PM, 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/1938dd18e1d25b8c03e4cb2228627... [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3]
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I don't have a strong opinion but it should be one of the following IMO: 1) we don't care about the date in XML (which is the current situation in practice since we never ruled on this and we don't apply the same rule) 2) XAR format forces a specific date in the XML (but hard to find one that make sense) 3) XAR format remove the date element from the XML (which means that the date will be the install/import date) 4) the date in the XML is the date of the last commit (but hard to make sure it's always true, maybe some git tag like the id tag we are using in Java files ?) 5) the date in the XML is the release date (means adding this in the release script but it's a pity for extensions) On Mon, Jul 25, 2016 at 2:08 PM, 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.
No, there is no relationship between the version and the date in this context.
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.
But which date ?
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/1938dd18e1d25b8c03e4cb2228627... [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3] http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, Jul 25, 2016 at 2:34 PM, Thomas Mortagne <[email protected]> wrote:
I don't have a strong opinion but it should be one of the following IMO:
1) we don't care about the date in XML (which is the current situation in practice since we never ruled on this and we don't apply the same rule) 2) XAR format forces a specific date in the XML (but hard to find one that make sense) 3) XAR format remove the date element from the XML (which means that the date will be the install/import date) 4) the date in the XML is the date of the last commit (but hard to make sure it's always true, maybe some git tag like the id tag we are using in Java files ?) 5) the date in the XML is the release date (means adding this in the release script but it's a pity for extensions)
On Mon, Jul 25, 2016 at 2:08 PM, 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.
No, there is no relationship between the version and the date in this context.
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.
Imports and installs are not taken into account by activity stream which seems well enough to not have system pages end up in changes reports.
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.
But which date ?
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/1938dd18e1d25b8c03e4cb2228627... [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3] http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
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) * 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/1938dd18e1d25b8c03e4cb2228627... [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3] http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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) 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. 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. 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.
* 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/1938dd18e1d25b8c03e4cb2228627...
[2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3]
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/1938dd18e1d25b8c03e4cb2228627...
[2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3]
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
_______________________________________________ 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
participants (4)
-
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol