Re: [xwiki-devs] Next version for 9.x cycle

[Vincent Massol]

> On 19 Dec 2017, at 14:50, Thomas Mortagne  wrote:
> 
> Fine with me but that means we need to fix master branch in github
> which has a wrong version right now.

Indeed! Let’s do this (unless someone disagrees?).

Thanks
-Vincent

> 
> On Tue, Dec 19, 2017 at 1:17 PM, Alex Cotiugă
>  wrote:
>> +0
>> 
>> Thanks,
>> Alex
>> 
>> On Tue, Dec 19, 2017 at 2:04 PM, Vincent Massol  wrote:
>> 
>>> 
>>> 
 On 19 Dec 2017, at 13:03, Vincent Massol  wrote:
 
 In term of dates, I’m proposing to have 2 weeks since that’s what we
>>> usually do for bug fix releases. Since there’s christmas and new year, I’m
>>> proposing to add one more week:
 
 9.11.1 - 8th of Jan 2018.
 
 WDYT?
>>> 
>>> Note that we’ll have a 9.11.2 after we release 9.11.1 so if someone
>>> couldn’t be done in 9.11.1 it’ll be done in 9.11.1 and later.
>>> 
>>> Thanks
>>> -Vincent
>>> 
 
 Thanks
 -Vincent
 
 
> On 19 Dec 2017, at 12:02, Vincent Massol  wrote:
> 
> Hi devs,
> 
> We need to decide what’s our next version for 9.x.
> 
> Since 9.11 is supposed to be the last release (actually 9.10 was even
>>> supposed to be the last one according to http://dev.xwiki.org/xwiki/
>>> bin/view/Community/VersioningAndReleasePractices#
>>> HReleaseCyclesandReleaseStrategy we might need to change that).
> 
> We still have some stuff to stabilize: notifications, shortcuts, etc.
> 
> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep
>>> the strategy of 12 main releases per year, and to start stabilizing the 9.x
>>> cycle.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 
> 
> 
 
>>> 
>>> 
> 
> 
> 
> -- 
> Thomas Mortagne

Re: [xwiki-devs] Next version for 9.x cycle

[Thomas Mortagne]

Fine with me but that means we need to fix master branch in github
which has a wrong version right now.

On Tue, Dec 19, 2017 at 1:17 PM, Alex Cotiugă
 wrote:
> +0
>
> Thanks,
> Alex
>
> On Tue, Dec 19, 2017 at 2:04 PM, Vincent Massol  wrote:
>
>>
>>
>> > On 19 Dec 2017, at 13:03, Vincent Massol  wrote:
>> >
>> > In term of dates, I’m proposing to have 2 weeks since that’s what we
>> usually do for bug fix releases. Since there’s christmas and new year, I’m
>> proposing to add one more week:
>> >
>> > 9.11.1 - 8th of Jan 2018.
>> >
>> > WDYT?
>>
>> Note that we’ll have a 9.11.2 after we release 9.11.1 so if someone
>> couldn’t be done in 9.11.1 it’ll be done in 9.11.1 and later.
>>
>> Thanks
>> -Vincent
>>
>> >
>> > Thanks
>> > -Vincent
>> >
>> >
>> >> On 19 Dec 2017, at 12:02, Vincent Massol  wrote:
>> >>
>> >> Hi devs,
>> >>
>> >> We need to decide what’s our next version for 9.x.
>> >>
>> >> Since 9.11 is supposed to be the last release (actually 9.10 was even
>> supposed to be the last one according to http://dev.xwiki.org/xwiki/
>> bin/view/Community/VersioningAndReleasePractices#
>> HReleaseCyclesandReleaseStrategy we might need to change that).
>> >>
>> >> We still have some stuff to stabilize: notifications, shortcuts, etc.
>> >>
>> >> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep
>> the strategy of 12 main releases per year, and to start stabilizing the 9.x
>> cycle.
>> >>
>> >> WDYT?
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >>
>> >>
>> >
>>
>>



-- 
Thomas Mortagne

Re: [xwiki-devs] Next version for 9.x cycle

[Alex Cotiugă]

+0

Thanks,
Alex

On Tue, Dec 19, 2017 at 2:04 PM, Vincent Massol  wrote:

>
>
> > On 19 Dec 2017, at 13:03, Vincent Massol  wrote:
> >
> > In term of dates, I’m proposing to have 2 weeks since that’s what we
> usually do for bug fix releases. Since there’s christmas and new year, I’m
> proposing to add one more week:
> >
> > 9.11.1 - 8th of Jan 2018.
> >
> > WDYT?
>
> Note that we’ll have a 9.11.2 after we release 9.11.1 so if someone
> couldn’t be done in 9.11.1 it’ll be done in 9.11.1 and later.
>
> Thanks
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> >
> >> On 19 Dec 2017, at 12:02, Vincent Massol  wrote:
> >>
> >> Hi devs,
> >>
> >> We need to decide what’s our next version for 9.x.
> >>
> >> Since 9.11 is supposed to be the last release (actually 9.10 was even
> supposed to be the last one according to http://dev.xwiki.org/xwiki/
> bin/view/Community/VersioningAndReleasePractices#
> HReleaseCyclesandReleaseStrategy we might need to change that).
> >>
> >> We still have some stuff to stabilize: notifications, shortcuts, etc.
> >>
> >> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep
> the strategy of 12 main releases per year, and to start stabilizing the 9.x
> cycle.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
> >>
> >
>
>

Re: [xwiki-devs] Next version for 9.x cycle

[Vincent Massol]

> On 19 Dec 2017, at 13:03, Vincent Massol  wrote:
> 
> In term of dates, I’m proposing to have 2 weeks since that’s what we usually 
> do for bug fix releases. Since there’s christmas and new year, I’m proposing 
> to add one more week:
> 
> 9.11.1 - 8th of Jan 2018.
> 
> WDYT?

Note that we’ll have a 9.11.2 after we release 9.11.1 so if someone couldn’t be 
done in 9.11.1 it’ll be done in 9.11.1 and later.

Thanks
-Vincent

> 
> Thanks
> -Vincent
> 
> 
>> On 19 Dec 2017, at 12:02, Vincent Massol  wrote:
>> 
>> Hi devs,
>> 
>> We need to decide what’s our next version for 9.x.
>> 
>> Since 9.11 is supposed to be the last release (actually 9.10 was even 
>> supposed to be the last one according to 
>> http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#HReleaseCyclesandReleaseStrategy
>>  we might need to change that).
>> 
>> We still have some stuff to stabilize: notifications, shortcuts, etc.
>> 
>> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the 
>> strategy of 12 main releases per year, and to start stabilizing the 9.x 
>> cycle.
>> 
>> WDYT?
>> 
>> Thanks
>> -Vincent
>> 
>> 
>> 
> 

Re: [xwiki-devs] Next version for 9.x cycle

[Vincent Massol]

In term of dates, I’m proposing to have 2 weeks since that’s what we usually do 
for bug fix releases. Since there’s christmas and new year, I’m proposing to 
add one more week:

9.11.1 - 8th of Jan 2018.

WDYT?

Thanks
-Vincent


> On 19 Dec 2017, at 12:02, Vincent Massol  wrote:
> 
> Hi devs,
> 
> We need to decide what’s our next version for 9.x.
> 
> Since 9.11 is supposed to be the last release (actually 9.10 was even 
> supposed to be the last one according to 
> http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#HReleaseCyclesandReleaseStrategy
>  we might need to change that).
> 
> We still have some stuff to stabilize: notifications, shortcuts, etc.
> 
> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the 
> strategy of 12 main releases per year, and to start stabilizing the 9.x cycle.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 
> 
> 

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Eduard Moraru]

Hi,

Yes, this makes sense because in the previous "doc:PageB" version, the link
was in relative form (no space specified) and it was resolved to the
current space (which was "Public" when PageA was in the "Public" space).
After NS, using "doc:Draft.PageB.WebHome" means using a very explicit and
absolute reference that does no resolution so it will behave the same,
regardless of the context where PageA(.WebHome) is located (hence, it will
link to the "Draft" space).

There are a couple of cases where you could get away with it without any
refactoring and using advanced knowledge on xwiki's link syntax resolution
algorithm. TL;DR; These are the ones that involve links coming from higher
in the hierarchy towards pages lower in the hierarchy or when linking
between sibling pages (i.e. same level in the hierarchy).
You can find more details on
http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1§ion=Links
(see the "[[.PageA]]" and "[[.PageA.PageB]]" examples and then the details
on the resolution of "Untyped" links).

Now, I have mentioned this just for the sake of completeness on the matter
and would not really advise to rely on these "relative" links, since they
are currently more of a side effect of our current model than a feature
that is well-thought and recommended (e.g. we don't have support for
relative links upper in the hierarchy like "../../PageX").

Given the proper support for relative links in our syntax, indeed, the
listener and link fixing solution would be the recommended one.

Hope this helps,
Eduard

On Sat, Dec 16, 2017 at 2:06 PM, Anca Luca  wrote:

> Hello Clemens,
>
> Indeed, this is _one_ of the problems that the workflow application has on
> a "nested" environment.
>
> I think it's a good approach for the fix, the only thing that you should
> try to take care of is to make this as generic as possible wrt the
> configured draft space in the publication workflow config of the document
> being published (fix links relative to this space). Don't hesitate, if
> needed, to add a configuration of the "default publication space" in the
> publication workflow config, I found the need for it in other situations as
> well, so it won't hurt.
>
> Also, one issue I can think of (which is related to the other issues that
> publication workflow has on nested) is that the page to which the link is
> might not yet be published, and in this case, imo, the link should be
> refactored and be a "broken link" until the target page gets published.
>
> Thanks for working on this,
> Anca
>
> On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar <
> c.robbenh...@posteo.de
> > wrote:
>
> > Hi Devs,
> >
> >  some users reported a problem to me concerning the Publication Workflow
> > Application and the nested pages feature.
> > The problem is as follows:
> >
> >  In their old instance (some 6.4.x) they had a draft space and a public
> > space and workflows attaching each page in the draft space with a page in
> > the public space in an 1:1 manner, like:
> >
> >   Draft.WebHome --> Public.WebHome
> >   Draft.PageA   --> Public.PageA
> >   Draft.PageB   --> Public.PageB
> >
> > Now if a link in, say, PageA in the Draft space points to another page,
> > e.g. PageB, this is done via a relative link like [[link
> text>>doc:PageB]]
> > After publishing PageA, the link of the published variant points to the
> > published variant of PageB (and not the variant in the Draft space),
> which
> > is the desired effect from the users point of view.
> >
> > Now after migration to 9.10 the situation is as follows:
> >
> >   Draft.WebHome--> Public.WebHome
> >   Draft.PageA.WebHome  --> Public.PageA.WebHome
> >   Draft.PageB.WebHome  --> Public.PageB.WebHome
> >
> > Now a link to PageB in PageA looks like: [[link
> > text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> > same space, but each in their own space.
> > Publishing the draft makes the link in the published variant point back
> to
> > the Draft space, of course. However this is different from the behavior
> > before nested pages and the users experience this as a bug.
> >
> > A manual solution would be to edit all pages and make the links point to
> > the published variant of the pages. However this is not only a cumbersome
> > and error prone task, but also the users are used to the "automatic" link
> > conversion that made links in the published variant point to published
> > pages and are wont to continue setting links to pages in the draft space,
> > expecting them to point to the "right place" after publishing.
> > The fact that now titles are used throughout in the navigation tree, and
> > the titles of the draft and published variant are usually the same and
> thus
> > indistinguishable complicates the problem even more.
> >
> > To fix this I could write a separate extension that listens to Publish
> > events send from the Workflow extension, and which converts the links in
> > the published varia

Re: [xwiki-devs] Next version for 9.x cycle

[Ecaterina Moraru (Valica)]

+0

Thanks,
Caty

On Tue, Dec 19, 2017 at 1:02 PM, Vincent Massol  wrote:

> Hi devs,
>
> We need to decide what’s our next version for 9.x.
>
> Since 9.11 is supposed to be the last release (actually 9.10 was even
> supposed to be the last one according to http://dev.xwiki.org/xwiki/
> bin/view/Community/VersioningAndReleasePractices#
> HReleaseCyclesandReleaseStrategy we might need to change that).
>
> We still have some stuff to stabilize: notifications, shortcuts, etc.
>
> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the
> strategy of 12 main releases per year, and to start stabilizing the 9.x
> cycle.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>
>

Re: [xwiki-devs] Next version for 9.x cycle

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Tue, Dec 19, 2017 at 1:02 PM, Vincent Massol  wrote:

> Hi devs,
>
> We need to decide what’s our next version for 9.x.
>
> Since 9.11 is supposed to be the last release (actually 9.10 was even
> supposed to be the last one according to http://dev.xwiki.org/xwiki/
> bin/view/Community/VersioningAndReleasePractices#
> HReleaseCyclesandReleaseStrategy we might need to change that).
>
> We still have some stuff to stabilize: notifications, shortcuts, etc.
>
> So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the
> strategy of 12 main releases per year, and to start stabilizing the 9.x
> cycle.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>
>

[xwiki-devs] Next version for 9.x cycle

[Vincent Massol]

Hi devs,

We need to decide what’s our next version for 9.x.

Since 9.11 is supposed to be the last release (actually 9.10 was even supposed 
to be the last one according to 
http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#HReleaseCyclesandReleaseStrategy
 we might need to change that).

We still have some stuff to stabilize: notifications, shortcuts, etc.

So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the 
strategy of 12 main releases per year, and to start stabilizing the 9.x cycle.

WDYT?

Thanks
-Vincent

Re: [xwiki-devs] [ANN] XWiki 9.11 released

[Marius Dumitru Florea]

Regarding the shortcuts, we have this issue reported
http://jira.xwiki.org/browse/XWIKI-14907 .

On Tue, Dec 19, 2017 at 12:31 PM, Ludovic Dubost  wrote:

> Nice :)
>
>
>- The key sequence *X*, *X*, *X*, *A* toggles the "advanced user mode"
> PageEditing#HAdvancedMode>
> for
>the currently logged in user. Performing this sequence as an advanced
> user
>will switch it back to the "simple user mode"
> PageEditing#HSimpleMode>
> (the
>default).
>- The key sequence *X*, *X*, *X*, *H* toggles the "show hidden pages"
>option
> PageEditing#HHidingPages3>
> for
>the currently logged in user. Performing this sequence while already
>viewing hidden pages will switch back to hiding hidden pages (the
> default).
>
>
> Congrats !
>
>
>
> --
> *Ludovic Dubost*
> *Founder and CEO*
> ludo...@xwiki.com
> skype: ldubost
> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>   - Try Cryptpad: Secure
> realtime Wysiwyg Editing 
>
>
> On Tue, Dec 19, 2017 at 11:23 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > The XWiki development team is proud to announce the availability of XWiki
> > 9.11.
> > This release brings some final touches to the notifications module by
> > improving the look and feel of the notification center and the
> notification
> > emails.
> > Some optimizations have also been made in order to speed up the loading
> > time of the notifications tray.
> >
> > You can download it here: http://www.xwiki.org/xwiki/
> > bin/view/Main/Download
> >
> > Make sure to review the release notes:
> > http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11
> >
> > Thanks for your support
> > -The XWiki dev team
> >
>

Re: [xwiki-devs] [ANN] XWiki 9.11 released

[Ludovic Dubost]

Nice :)


   - The key sequence *X*, *X*, *X*, *A* toggles the "advanced user mode"
   

for
   the currently logged in user. Performing this sequence as an advanced user
   will switch it back to the "simple user mode"
   

(the
   default).
   - The key sequence *X*, *X*, *X*, *H* toggles the "show hidden pages"
   option
   

for
   the currently logged in user. Performing this sequence while already
   viewing hidden pages will switch back to hiding hidden pages (the default).


Congrats !



--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad: Secure
realtime Wysiwyg Editing 


On Tue, Dec 19, 2017 at 11:23 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> The XWiki development team is proud to announce the availability of XWiki
> 9.11.
> This release brings some final touches to the notifications module by
> improving the look and feel of the notification center and the notification
> emails.
> Some optimizations have also been made in order to speed up the loading
> time of the notifications tray.
>
> You can download it here: http://www.xwiki.org/xwiki/
> bin/view/Main/Download
>
> Make sure to review the release notes:
> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11
>
> Thanks for your support
> -The XWiki dev team
>

[xwiki-devs] [ANN] XWiki 9.11 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
9.11.
This release brings some final touches to the notifications module by
improving the look and feel of the notification center and the notification
emails.
Some optimizations have also been made in order to speed up the loading
time of the notifications tray.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11

Thanks for your support
-The XWiki dev team