- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Release Candidate 1 Released
by Marius Dumitru Florea 20 Jan '12

20 Jan '12

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Release Candidate 1. The first release candidate of the 3.4 version brings a few bug fixes and improvements over the previous version. The most notable addition is the possibility to easily import an extension from any repository into XWiki Repository. You can find the full list of issues fixed for this release at http://goo.gl/G9InJ . See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

3 3

[xwiki-devs] Wrongly deprecated xe.pagination.* translation properties?
by Vincent Massol 20 Jan '12

20 Jan '12

Hi Sergiu, I've seen you committed the following below. I'm now renaming properties since I' m moving the livetable to platform. You've marked 2 properties as "deprecated": +# Deprecated: xe.pagination.results=Results xe.pagination.results.of=out of However they're are still used in livetable.js. How come? Thanks -Vincent Author: sdumitriu Date: 2009-05-22 15:09:39 +0200 (Fri, 22 May 2009) New Revision: 20272 Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties Log: XWIKI-3880: Improve the pagination aspect Adding resources Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties =================================================================== --- platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-05-22 12:57:04 UTC (rev 20271) +++ platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-05-22 13:09:39 UTC (rev 20272) @@ -1675,11 +1675,19 @@ xe.space.index=Space Index xe.space.index.description=This page lists all your wiki's spaces +xe.pagination.page=Page +xe.pagination.page.title=Go to page {0} +xe.pagination.page.previous=« previous page +xe.pagination.page.prev.title=Previous Page +xe.pagination.page.next=next page » +xe.pagination.page.next.title=Next Page +xe.pagination.results.none=No results +xe.pagination.results.one=One result +xe.pagination.results.single=Result {0} of {1} +xe.pagination.results.many=Results {0} - {1} of {2} +# Deprecated: xe.pagination.results=Results xe.pagination.results.of=out of -xe.pagination.page=Page -xe.pagination.page.next.title=Next Page -xe.pagination.page.prev.title=Previous Page xe.livetable._actions.delete=delete xe.livetable._actions.rename=rename

2 1

[xwiki-devs] [VOTE] Mark the xwiki/1.0 syntax as deprecated
by Sergiu Dumitriu 18 Jan '12

18 Jan '12

Hi devs, Since a long time ago, the xwiki/1.0 syntax has been deprecated in favor of the new rendering engine and the 2.x syntaxes, but this has never been declared deprecated formally. We should: * mark the syntax as deprecated in the UI (like 2.1 was marked experimental in the syntax choice dropdown) * deprecate classes and methods that deal only with the old syntax * push more for migrating all documents to the 2.1 syntax; the biggest troublemaker is the statistics application Here's my +1. We should also decide on a timeline for the complete removal of the 1.0 syntax. Is that something we want to do? Provided we manage to migrate all the official documents and some major contributed applications during the 4.x cycle, is XWiki 5.0 a good target? We should package the support for xwiki/1.0 as an optional extension installable using the extension manager, so that people can upgrade from older versions. Or we could package just a syntax migrator that can be used for an automatic conversion to a newer syntax, without actually providing rendering support for it. -- Sergiu Dumitriu http://purl.org/net/sergiu/

11 13

[xwiki-devs] [Discussion] Release strategy and slippages - Timeboxing
by Vincent Massol 16 Jan '12

16 Jan '12

Hi devs, We've been quite bad at following the release strategy we've defined so far: timeboxing. We've been constantly slipping our release dates during all the past releases (and not by 1 or 2 days, but by 2 weeks or more). Personally I find this not professional of us and for me it means that the date we give are just a joke now. I don't even see why we're giving dates since they can only be misleading to anyone who would act on them… At the current slippage rate, we should only give a month estimation to have a chance of being correct ;) There's only one reason we're really slipping IMO: we've forgotten that we're doing time boxing. Let me remind us what time boxing is and how it can be made to work: * It means releasing on a fixed date and releasing whatever is ready at that date. * The idea is also to do quick releases so that if a given feature is not in a release it'll be in the next one coming soon (we used to do 2 to 3 weeks releases at some points and recently we've been doing instead 3-5 weeks instead) * The reason for releasing often is because this pushes the bug fixes and new stuff to users ASAP and thus let them experiment with them and give us feedback (bugs, usability, etc) * The way to make timeboxing work is by having automated functional tests so that we can release safely knowing that our test suite will catch the problems if any. This means that whenever a commit is done, in the same commit there are tests proving that what is committed is working (and not several weeks later which would be anti-timeboxing). * it doesn't mean we cannot have a roadmap. What it means is that we should the maximum of what is in the roadmap in a given time slot. What's not done doesn't get released. This means that large features should be divided into small one that will fit. Developers need to think about what they're doing by constantly checking the release date and verifying what they can achieve for that date and make absolutely sure that what they have committed is working for that date (even if what they have committed is not finished). * Timeboxing is not about how many men/days you have available or whether people are on holidays or not. If you have less men/days you do less work. It doesn't change the release date. Basically you can only do timeboxing if you have good and automated quality control. The opposite of timeboxing is feature releases which lead to the following: * People committing not working stuff or without tests because they know they'll have time to fix it later on before the release (easy to think this since there's no release date, it's only when the features are done that it'll get released) * Release date become not important since they keep being pushed since what's important is to release planned features * Build failing all the time and developers not caring about it ("it can always be fixed later when we get close to the release date" - that's easy to say since there' no fixed release date) * Users seeing less frequent releases and giving less feedback to developers (thus helping less) * In general, quality dropping over time So we have several choices: 1) Forget timeboxing and do feature-based releases, i.e. we list features and we only release when they're done 2) Start doing real timeboxing again I've seen so many projects do 1) in the past with such bad results that for me there's no doubt that the only good strategy is 2). Especially for an open source project which has a strong community and we should be releasing stuff regularly and quickly to this community to get good feedback. Doing timeboxing is also a great way to improve the quality of our code. Timeboxing can only work fine if everyone agrees with it (we can revert stuff from a developer if it breaks things but it's a pain) and believe in the release date, so we'd need everyone's agreements. So WDYT, are we ok to resume doing timeboxing and go back on track? On my side I'm ok to do it and help enforce it. If we agree we should start now by releasing RC1 ASAP and give a new date for 3.4 final and release on that date. Thanks -Vincent

3 4

[xwiki-devs] [Vote] Release 3.4RC1 ASAP (today/tomorrow) ?
by Marius Dumitru Florea 16 Jan '12

16 Jan '12

Hi devs, What do you prefer: (1) Release 3.4RC1 today or tomorrow (depending on how much time it takes to fix the failing tests on CI and any blockers -- please list them) and release 3.4 final this Thursday, 19 January. (2) Release 3.4RC1 at the end of this week (Thursday/Friday) and release 3.4 final at the start of the next week, 23 January. I'm more for (2) because it would allow me to include some fixes to the AppWithinMinutes that I couldn't do in 3.4M1 because I was busy with fixing failing tests on CI, doing the actual release and writing the release notes. Thanks, Marius

3 5

[xwiki-devs] List of users property in a class within a workspace
by Ido Meshi 15 Jan '12

15 Jan '12

1 0

[xwiki-devs] Fwd: Happy to announce the creation of XWiki Clams Core + XClams Wiki
by Ludovic Dubost 14 Jan '12

14 Jan '12

News on XWiki CLAMS (Curriki) ---------- Forwarded message ---------- From: Ludovic Dubost <ludovic(a)xwiki.com> Date: 2012/1/14 Subject: Happy to announce the creation of XWiki Clams Core + XClams Wiki To: xclams-devs(a)xwiki.org Hi, I'm happy to announce that the migration process from SVN to GitHub and creation of the XClams and Curriki.org project went very well. We know have: https://github.com/xwiki-contrib/xwiki-clams-core with the curriki-2.0, curriki-2.1 and the master branch https://github.com/xwiki-contrib/currikiorg with the curriki 1.8 and older branches The Sankore source code will come soon We also have: A brand new Wiki: http://xclams.xwiki.org with more information about the project, the community and the committers I've also published the current velocity APIs in the current xwiki-clams-core: http://xclams.xwiki.org/xwiki/bin/view/Design/XClamsVelocityAPIsV22 The next steps are: - the publishing of the Sankore Source Code - changing the jenkins build to the GitHub source - bringing back many patches from Sankore into xwiki-clams-core - create the xwiki-clams-demo project with clean default data for a XClams based project - bring back Curriki.org on the master branch Thanks a lot to Sergiu for his help Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0

[xwiki-devs] XCLAMS mailing list on markmail
by Ludovic Dubost 14 Jan '12

14 Jan '12

Hi, The migration of Curriki to XClams is progressing. Thanks to Sergiu we now have the xclams-core and currikiorg projects on GitHub. Thanks Sergiu. I'm currently working on preparing xclams.xwiki.org. While doing that, I think it would be nice to archive the xclams-dev mailing list on markmail and nabble. I'm not sure how to do that. I'm sure Vincent can help ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1 Released
by Marius Dumitru Florea 13 Jan '12

13 Jan '12

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1. This is the first and only milestone of the 3.4 version. We're getting closer to the end of the 3.x cycle and the goal of this release (and the following one, which will be the last of the cycle) is to improve the current features. The highlights of this release are: * New default color theme * XWiki 2.1 is the default page syntax * Delete space menu * Simple space templates * Special characters in attachment name * Minimized action menu * Display macro * Improved Extension Manager UI See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

1 0

[xwiki-devs] Get current space [velocity]
by Hamster 13 Jan '12

13 Jan '12

This should be easy, but I am stuck :-( I have created a new panel. The panel shows all the document in the current space. But if the user is in the Main Space, I don't want to show any documents, I want to show all the spaces (except for a couple default spaces). #if $currentSpace = "Main" #set ($hiddenSpaces = ["AnnotationCode", "ColorThemes", "Invitation", "Panels", "Scheduler", "Stats", "XWiki"]) #set($spacesSorted=$xwiki.sort($xwiki.spaces) ) #foreach($space in $spacesSorted) #if (!$hiddenSpaces.contains($space)) * [[$space>>${space}.WebHome]] #end #end #else // Code which shows all documents #end How do I know when I am in the Main Space? -- View this message in context: http://xwiki.475771.n2.nabble.com/Get-current-space-velocity-tp7183403p7183… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 2