Hi devs,
We’ve just released XWiki 9.10. Let’s now define what we’ll do till the end of the year, i.e. for XWiki 9.11.
The proposal is to have 9.11 be mostly a stabilization release.
Here’s a proposal:
* Finish FS-based attachments but don’t turn it on by default. It’ll be turned on in XWiki 10.0. Thomas already started on this in XWiki 9.10. - Thomas
* Protect edition of pages coming from Extensions, in order to try improving upgrades. - Thomas
* Polishing of Notifications and performance check/improvemnt (It's very important to disable it and recheck the perf report to compare with 8.4.5 to see if the problem comes from notifs for ex). - Guillaume
* Generally, bug fixes/stabilization - All
Dates:
* 9.11RC1: 11 Dec
* 9.11Final: 18 Dec (as a target but could go till end of the year)
Note:
* Knowing that Guillaume won’t have much during this period, it’s likely that Notifications won’t be polished enough to be marked as production level ready in 9.11 and we’ll probably need a 9.12 or 9.11.1 release in January for that.
WDYT? Anything else someone would like to do?
As usual please update http://www.xwiki.org/xwiki/bin/view/Roadmaps/ with the detailed list of JIRA tasks for each topic.
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki 9.10.
This is mostly a release focusing on improving the new Notifications
feature, in order to make it as polished and usable as possible before
the end of the year (i.e. before the end of the Cycle and before we
elect a new LTS release). It also contains several bug fixes.
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.10
Thanks for your support
-The XWiki dev team
The XWiki development team is proud to announce the availability of XWiki 9.10RC1.
This is mostly a release focusing on improving the new Notifications feature, in order to make it as polished and usable as possible before the end of the year (i.e. before the end of the Cycle and before we elect a new LTS release). It also contains several bug fixes.
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.10RC1/
Thanks for your support
-The XWiki dev team
Hi devs,
We started to think about https://jira.xwiki.org/browse/XWIKI-14377
with Caty and she noticed that it might not be as simple as "all
extensions pages are protected" because there is extensions pages that
are almost always supposed to be modified: first example is
Main.WebHome which is modified 99% of the time but another good one is
Sandbox or Quicklinks panel.
So what do we do about it ?
I'm not fully sure yet but here are some ideas :
1) So what ? It's still extension pages and you might still have
conflicts during next upgrade. If you want standard pages to be
modified then generate them during install.
2) Only show the warning when a page is hidden and consider all non
hidden pages as OK to modify
3) Explicitly mark each standard page that is OK to be modified with
some xobject
3.a) EM XAR handler behave with these pages as it always did
3.b) EM XAR handler has a special support for these pages controlled
by one of the xobject fields (skip the document from any merge if
there is any customization, always overwrite any customization, etc.)
WDYT ?
1) might be too harsh, generating Main.WebHome might be doable (but
still a pain to maintain) but it's quite a pain to generate the whole
Sandbox space (and not even talking about maintaining it...)
2) we might still want to see some application home pages in the
search result and most of them should really not be modified
3.a) will still have the "what should I do" effect sometime for pages
that user is allowed to modify
3.b) has my preference right now, sounds like the nicest from user and
author point of view, can even be used for other use cases than edit
protection control
--
Thomas Mortagne