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

[Marius Dumitru Florea]

On Thu, Jul 28, 2016 at 10:21 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> To be honest, I use git add -p and, sometimes, it happens to have in the
> same hunk with date fields, some changes that I want to commit, so I have
> to edit that hunk and to manually revert the date changes. Hope my use case
> is more clear now.
>

You can use the "s" (split) option when you encounter such a group of
changes.


>
>
> On Thu, Jul 28, 2016 at 12:14 AM, Sergiu Dumitriu 
> wrote:
>
> > git add --interactive
> >
> > On 07/27/2016 03:59 AM, Alexandru Cotiuga wrote:
> > > 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.morta...@xwiki.com
> > >> wrote:
> > >
> > >> Le 25 juil. 2016 18:31, "Vincent Massol"  a
> écrit :
> > >>>
> > >>>
> >  On 25 Jul 2016, at 18:20, Eduard Moraru 
> wrote:
> > 
> >  Hi,
> > 
> >  On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol  >
> > >> 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 
> > >> 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
> > >> 

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

[Alexandru Cotiuga]

To be honest, I use git add -p and, sometimes, it happens to have in the
same hunk with date fields, some changes that I want to commit, so I have
to edit that hunk and to manually revert the date changes. Hope my use case
is more clear now.


On Thu, Jul 28, 2016 at 12:14 AM, Sergiu Dumitriu  wrote:

> git add --interactive
>
> On 07/27/2016 03:59 AM, Alexandru Cotiuga wrote:
> > 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.morta...@xwiki.com
> >> wrote:
> >
> >> Le 25 juil. 2016 18:31, "Vincent Massol"  a écrit :
> >>>
> >>>
>  On 25 Jul 2016, at 18:20, Eduard Moraru  wrote:
> 
>  Hi,
> 
>  On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol 
> >> 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 
> >> 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
> >> 

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

[Sergiu Dumitriu]

git add --interactive

On 07/27/2016 03:59 AM, Alexandru Cotiuga wrote:
> 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 > wrote:
> 
>> Le 25 juil. 2016 18:31, "Vincent Massol"  a écrit :
>>>
>>>
 On 25 Jul 2016, at 18:20, Eduard Moraru  wrote:

 Hi,

 On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol 
>> 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 
>> 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
>>
>> 

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

[Alexandru Cotiuga]

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  wrote:

> Le 25 juil. 2016 18:31, "Vincent Massol"  a écrit :
> >
> >
> > > On 25 Jul 2016, at 18:20, Eduard Moraru  wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol 
> 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 
> 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]
> > >>>
> > >>
>
> 

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

[Thomas Mortagne]

Le 25 juil. 2016 18:31, "Vincent Massol"  a écrit :
>
>
> > On 25 Jul 2016, at 18:20, Eduard Moraru  wrote:
> >
> > Hi,
> >
> > On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol 
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  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
> >>> devs@xwiki.org
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >> ___
> >> devs mailing list
> >> devs@xwiki.org
> >> 

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

[Vincent Massol]

> On 25 Jul 2016, at 18:20, Eduard Moraru  wrote:
> 
> Hi,
> 
> On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol  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  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
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> 
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>> 
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Eduard Moraru]

Hi,

On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol  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  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
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Vincent Massol]

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  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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Thomas Mortagne]

On Mon, Jul 25, 2016 at 2:34 PM, Thomas Mortagne
 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  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/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
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Thomas Mortagne]

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  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/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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Marius Dumitru Florea]

+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  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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Eduard Moraru]

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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs