xwiki-devs November 2010

xwiki-devs@xwiki.org

37 participants
92 discussions

[xwiki-devs] [VOTE] Release XE and XEM 2.5.1

by Sergiu Dumitriu

Hi devs, It's been two weeks since the release of 2.5, and there have been some critical and not so critical bugfixes since. Most notably: - images no longer appear in documents imported from office documents - PDF styling was completely broken, now it has been greatly improved See the full list of fixed issues here: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=p… Does anybody want to commit something else? -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

[xwiki-devs] [Proposal] XE 3.0 and Roadmap leading to it

by Vincent Massol

Hi everyone, Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it. As Sergiu I believe we need a XE 3.0 ASAP for the following reasons: - it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing Before being able to release XE 3.0 I think: - XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011) Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now. Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect. WDYT? Thanks -Vincent

13 years, 11 months

[xwiki-devs] [Idea] Tools to help the release process

by Vincent Massol

Hi, I'm summarizing some idea I've had about some tools to help the release process: Idea 1: Create a semi-automated Release Plan page on xwiki.org =================================================== * Read the POM from http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution/jetty/hsql… (using aether) * Find all transitive dependencies (using aether) * For each dep: ** Read its POM ** Read the version from the pom, remove the SNAPSHOT part ** Read the JIRA URL from the pom ** Find the list of issues in jira with a fixfor equal to the read version ** If there are not closed issue display a warning message ** Display the list of issues found ** Read the SVN info from the POM to find the svn tag URL (using svnkit for example) ** With the version build a full URL ** Get the svn revision number of the last commit for that URL ** Do a svn log on trunk/ to find all commits since the last release ** Display them This should give a Release Plan Dashboard allowing the releaser to see at a glance what should be released, saving him the work to: - find all deps - find which modules have been modified and needs to be released Idea 2: Create a Release application on dev.xwiki.org ========================================== * A very simple application with a home listing all past releases that have been done already + a create new release button * When you press that create button it creates a new release page, copying a template page which has the release steps * Use the todo macro/application to list all the steps to be performed in the release, allowing the release to tick them visually as he progresses through the release (it's important to be able to tick a task in view mode - if we don't have this feature in an existing todo/task macro then develop it). WDYT? Would that help the release process? Any other ideas.? Thanks -Vincent

13 years, 11 months

Re: [xwiki-devs] [xwiki-notifications] r32334 - enterprise/trunk/wiki/src/main/resources/Main

by Vincent Massol

Hi, To be discussed but I'd rather we call the macro "activity" for several reasons: - it's shorter and easier to use (same reasoning as "avatar" vs "uservatar" macro) - it's more generic - we could want to add a parameter in the future that gives the time span (and it doesn't have specifically to be recent) Thanks -Vincent On Nov 2, 2010, at 6:13 PM, evalica (SVN) wrote: > Author: evalica > Date: 2010-11-02 18:13:48 +0100 (Tue, 02 Nov 2010) > New Revision: 32334 > > Modified: > enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml > enterprise/trunk/wiki/src/main/resources/Main/RecentActivity.xml > Log: > XE-736: Rename Main.RecentChanges to Main.RecentActivity to reflect the new implementation > - Changed macro name from recentchanges to recentactivity > > Modified: enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml 2010-11-02 17:02:56 UTC (rev 32333) > +++ enterprise/trunk/wiki/src/main/resources/Main/Dashboard.xml 2010-11-02 17:13:48 UTC (rev 32334) > @@ -217,12 +217,12 @@ > = $msg.get("xe.dashboard.wiki.recentactivity") = > #else > = $msg.get("xe.dashboard.space.recentactivity", [$doc.space]) = > - ## Set variables to limit recent changes to the current space and 15 items. > + ## Set variables to limit recent activity to the current space and 15 items. > #set ($rcSpace = $doc.space) > #set ($rcChangesNb = 15) > #end > > - {{recentchanges space="$!rcSpace" changesNb="$!rcChangesNb" /}} > + {{recentactivity space="$!rcSpace" changesNb="$!rcChangesNb" /}} > > ))) > ))) > > Modified: enterprise/trunk/wiki/src/main/resources/Main/RecentActivity.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/Main/RecentActivity.xml 2010-11-02 17:02:56 UTC (rev 32333) > +++ enterprise/trunk/wiki/src/main/resources/Main/RecentActivity.xml 2010-11-02 17:13:48 UTC (rev 32334) > @@ -1184,13 +1184,13 @@ > <defaultCategory>Content</defaultCategory> > </property> > <property> > -<description>Displays the recent changes in this wiki or in the passed space, if any.</description> > +<description>Displays the recent activity in this wiki or in the passed space, if any.</description> > </property> > <property> > -<id>recentchanges</id> > +<id>recentactivity</id> > </property> > <property> > -<name>Recent Changes</name> > +<name>Recent Activity</name> > </property> > <property> > <supportsInlineMode>0</supportsInlineMode> > @@ -1322,7 +1322,7 @@ > <defaultValue>true</defaultValue> > </property> > <property> > -<description>Whether to show differences for the items in the changes list or not.</description> > +<description>Whether to show differences for the items in the activity list or not.</description> > </property> > <property> > <mandatory>0</mandatory> > @@ -1388,7 +1388,7 @@ > <defaultValue>true</defaultValue> > </property> > <property> > -<description>Whether to show changes rss links or not.</description> > +<description>Whether to show activity rss links or not.</description> > </property> > <property> > <mandatory>0</mandatory> > @@ -1454,7 +1454,7 @@ > <defaultValue>30</defaultValue> > </property> > <property> > -<description>Number of changes to show.</description> > +<description>Number of activity to show.</description> > </property> > <property> > <mandatory>0</mandatory> > @@ -1520,7 +1520,7 @@ > <defaultValue></defaultValue> > </property> > <property> > -<description>Comma separated list of tags to display changes for.</description> > +<description>Comma separated list of tags to display activity for.</description> > </property> > <property> > <mandatory>0</mandatory> > @@ -1586,7 +1586,7 @@ > <defaultValue></defaultValue> > </property> > <property> > -<description>Comma separated list of spaces to display the recent changes for.</description> > +<description>Comma separated list of spaces to display the recent activity for.</description> > </property> > <property> > <mandatory>0</mandatory> > @@ -1663,7 +1663,7 @@ > </object> > <content>{{velocity}} > ## > -## Recent changes. > +## Recent Activity > ## > ## Optional parameters : > ## > @@ -1671,9 +1671,9 @@ > ## Note that HTTP parameters supercede velocity set variables. > ## > ## - rcShowRss (String set to "true" or "false"): show RSS at the bottom of the list. > -## - rcSpace (List of string[s]): restrict recent changes retrieval to pages within the given space. > -## - rcTag (List of string[s]): restrict recent changes retrieval to pages with the given tag. > -## - rcAuthor (List of string[s]): restrict recent changes retrieval to pages with the given author. > +## - rcSpace (List of string[s]): restrict recent activity retrieval to pages within the given space. > +## - rcTag (List of string[s]): restrict recent activity retrieval to pages with the given tag. > +## - rcAuthor (List of string[s]): restrict recent activity retrieval to pages with the given author. > ## - rcChangesNb (String set to a numerical value): number of pages to display recent activity. > ## - rcPagercPageEventsNo (String set to a numerical value): number of activity events displayed for each page. > ## > @@ -1705,7 +1705,7 @@ > #end > #end > ## pass the variables from the velocity context > -{{recentchanges #if($rcShowRss) showRss="$rcShowRss" #end > +{{recentactivity #if($rcShowRss) showRss="$rcShowRss" #end > #if($rcChangesNb) changesNb="$rcChangesNb" #end > #if($rcPagercPageEventsNb) changesNb="$rcPagercPageEventsNb" #end > #if($rcSpaceString) space="$rcSpaceString" #end

13 years, 11 months

[xwiki-devs] [Discussion] Recent Changes macro name and parameters

by Anca Luca

Hi devs, I've been working on http://jira.xwiki.org/jira/browse/XE-721 and it's done on my local. This is the recent changes macro based on the current implementation (not the activity stream one), but the idea is that we'll rewrite it to display recent activity in the future. I will commit it for the moment, in the 2.6 trunk, as is, but I would like to discuss here the name of the macro and its parameters: Macro name: recentchanges, changes, activity, recentactivity Parameters: * rss link should be shown at the bottom of the changes table (boolean): showRss, rss * minor changes are shown or not (boolean, default false): showMinor, minor * shows "see modifications" link next to entries (boolean, default true): showDiff, showDifferences, diff, differences * number of changes to show (number, 0 means "all", defaults to 30): changesNb, changesCount, number, count, limit * tags of documents to show chages for (comma separated list): tag, tags * spaces of documents to show changes for (comma separated list): space, spaces * authors of documents to show changes for (comma separated list): author, authors Note that the types cannot be enforced since it's a wiki macro, I put them there just for orientation. I'd go for activity rss minor diff count tags spaces authors . WDYT? Thanks, Anca

13 years, 11 months

[xwiki-devs] Invitation to connect on LinkedIn

by Apurv Gupta via LinkedIn

LinkedIn ------------Apurv Gupta requested to add you as a connection on LinkedIn: ------------------------------------------ Guillaume, I'd like to add you to my professional network on LinkedIn. - Apurv Accept invitation from Apurv Gupta http://www.linkedin.com/e/3vasf0-gg1qs8jc-5n/9s_c-0fN05p6qjQq9meQgfVB/blk/I… View invitation from Apurv Gupta http://www.linkedin.com/e/3vasf0-gg1qs8jc-5n/9s_c-0fN05p6qjQq9meQgfVB/blk/I… ------------------------------------------ DID YOU KNOW you can use your LinkedIn profile as your website? Select a vanity URL and then promote this address on your business cards, email signatures, website, etc http://www.linkedin.com/e/3vasf0-gg1qs8jc-5n/ewp/inv-21/ -- (c) 2010, LinkedIn Corporation

13 years, 11 months

[xwiki-devs] [VOTE] Enable xwiki/2.1 syntax by default in 2.6RC1

by Vincent Massol

Hi, I'd like to include xwiki/2.1 in the list of available syntaxes by default for 2.6RC1. Of course the default syntax remains xwiki/2.0. The rationale is: * Get people to know it exist and try it out as early as possible to provide feedback Note that it's marked (experimental) in the syntax combo box list so it should be enough to let people know about its status. Here's my +1 WDYT? Thanks -Vincent

13 years, 11 months

[xwiki-devs] [Proposal] Dynamic Search and Suggest widget improvements

by Jerome Velociter

Hello everyone, As I said in my answer to Vincent's mail about our roadmap leading to XWiki 3.0, I would like to include in this path some improvements to the Ajax Suggest widget, as well as a new high level feature : the "livesearch" (or whatever we will end up calling it) that provides dynamically search results "as you type" in the search box - and that uses those suggest widget improvements. I've started a design document at http://dev.xwiki.org/xwiki/bin/view/Design/SuggestImprovmentsAndDynamicSear… It includes some more details about the livesearch thing, including a breakdown plan with releases targets. Here is how I see it : * Redesign of the Ajax Suggest widget : 2.6 RC 2 (Note : this will be mostly a visual re-design for a start, I'm not planning on rewriting the widget from scratch - though some refactoring will be needed). * Capability for the suggest to display multiple groups of typed items (with icon and description) 2.6 RC 2 * Dynamic search (the "live search") : in the 2.7 cycle. I think it is too early to break this feature down in the releases of the 2.7 cycle. My +1 to have this new feature in 3.0, and to start the suggest widget improvements in 2.6. WDYT ? Note, I have started working with Caty on a suggest widget redesign proposal, I will send a mail about it very soon. Cheers, Jerome.

13 years, 11 months

[xwiki-devs] Apurv Gupta wants to stay in touch on LinkedIn

by Apurv Gupta via LinkedIn

LinkedIn ------------Apurv Gupta requested to add you as a connection on LinkedIn: ------------------------------------------ Guillaume, I'd like to add you to my professional network on LinkedIn. - Apurv Gupta Accept invitation from Apurv Gupta http://www.linkedin.com/e/3vasf0-gg121xqp-17/9s_c-0fN05p6qjQq9meQgfVB/blk/I… View invitation from Apurv Gupta http://www.linkedin.com/e/3vasf0-gg121xqp-17/9s_c-0fN05p6qjQq9meQgfVB/blk/I… ------------------------------------------ DID YOU KNOW you can use your LinkedIn profile as your website? Select a vanity URL and then promote this address on your business cards, email signatures, website, etc http://www.linkedin.com/e/3vasf0-gg121xqp-17/ewp/inv-21/ -- (c) 2010, LinkedIn Corporation

13 years, 11 months

Re: [xwiki-devs] Release Version Numbering Strategy (was Re: [Proposal] XE 3.0 and Roadmap leading to it)

by Gregory GUENEAU

Hi vincent, On 2 nov. 2010, at 08:56, Vincent Massol <vincent(a)massol.net> wrote: > Hi Ludovic, > > On Nov 1, 2010, at 6:05 PM, Ludovic Dubost wrote: > >> >> I've been thinking a little more about the XE 3.0 idea and I came to the conclusion that there should be no XWiki version called 3.0. >> >> Here is my thinking. I agree with something that was discussed by multiple people which is that a potential main version switch is the sign of a progress and of a cycle of development (preferably of a coherent feature set that we have thought about). >> The probleme is that if you call this version 3.0 then people will think of what software usually is developped (in the proprietary world), where 3.0 is a start with major changes in the software. >> >> Now when we look at the way open source and XWiki in particular develop software, this is not at all the case. We make gradual changes in the whole cycle of the software and there is not that many more changes between 1.9 and 2.0 then there was betwee 1.6 and 1.7. In this life we introduce new features all the time. Usually the first time a features goes in, it's not perfect and it's improved in the next release (with the biggest bugs fixed in minor releases). >> >> In order to recognize that and make it more understandable I suggest we don't call ANYTHING a .0 release. Instead I suggest that we start calling things the way they are, which are releases of a cycle which are improvements on a path that has been explained. >> Therefore we should NAME the major releases (instead of numbering them, although we keep the number for tracking) and we number the sub releases starting with 1 and not 0. >> >> For example if we call the 2.x cycle XXXXX and the 3.x cycle YYYYY, then we release >> >> XWiki 2.1 -> Cycle XXXXX release 1 -> subname for that release >> XWiki 2.2 -> Cycle XXXXX release 2 -> subname for that release >> XWiki 2.3 -> Cycle XXXXX release 3 -> subname for that release >> XWiki 2.4 -> Cycle XXXXX release 4 -> subname for that release >> >> For each release we show with features are in beta/stable state. Then at some point we work on full stabilitization and we advertise >> >> XWiki XXXXX release 7 with all features in there being stable >> >> Then we start the next cycle with release 1 >> >> XWiki YYYYY release 1 >> etc.. >> >> And we show the path and objectives of the whole cycle in order to show some coherency. >> >> This way we avoid the .0 issues where it's not clear if a .0 is stable or not, the beginning or the end. >> >> -- >> >> Concerning the plan, I'm +1 for stabilitzation work. -0 for calling the result 3.0. >> +1 for calling the next release following 2.7, version 3.1 but having new features in them showing the path of the next development cycle. >> and +1 for finding a text naming instead of numbers >> >> For the next cycle (3) we would need to find a nice name that shows the path we want to follow. > > I don't like skipping a version. It's confusing and not logical (from a number POV) IMO. > > I'd be ok with one of the following strategies (listed in the order of my preference): > > 1) Same as now. I don't see it a problem at all. I'm not completely sure why we're having this discussion. Have many users raised a question regarding our current release scheme? If we balance marketing needs in release numbering i am +1 The question is therefore : how do we merge those interrest in a reliable process ? > > 2) Same as now but we don't release major versions for "marketing" reasons (like we did for the 2.0 release), i.e. we only make a major release when there's a large non backward compatible change (say for example when we introduce the new model, or a move to JCR for example as the new storage mechanism, etc). This means we could have a 2.55 version. -0 on this, i am not sure this reaches our goals > > 3) No major releases at all. This means that we acknowledge that we don't need them since we're making evolutive changes (without major breakages or breakages are done evolutively too with deprecation cycles, etc). This would mean a new numbering scheme that doesn't have a major value. For ex: Release 25, 26, ... 150, etc. I like that it's based on numbers since you know the previous and the next one easily (and technically it'll work with Maven, no need for a custom version comparator). +0 it could be a good way to remove any marketing issue from the numbering strategy, but it kills value > > Thanks > -Vincent > >> Ludovic >> >>> On Nov 1, 2010, at 12:50 PM, Gregory GUENEAU wrote: >>> >>>> Hi everyone, >>>> >>>> I am +1 to make stabilization work, on a couple of releases >>>> I am +1 to have soon a 3.0 release >>>> And i am +1 on the content vincent propose >>>> >>>> But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family. >>>> >>>> Therefore : >>>> - do we consider a january 2011 release to be stable enough ? >>> Speaking for myself of course... >>> >>> yes (otherwise I wouldn't have proposed it obviously). >>> >>>> - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? >>> no, it's the same. >>> >>>> - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. >>> not needed to decide on the 3.0 release, this is a topic for another mail. >>> >>>> - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? >>> not needed at this stage >>> >>>> - do we have a clear consensus short list of features that show the path of 3.x family ? >>> not needed at this stage >>> >>>> - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? >>> not needed at this stage >>> >>>> - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? >>> yes (the content is open of course but provided it's not important new stuff IMO since otherwise it won't be about stabilization). >>> >>>> We have to make 100% sure our message will be understood by market. We are now in the Gartner magic quadrant and will increase our visibility outside the opensource community. >>>> In a world where new release number families means : "we show the path of the future of this software, even if the features we present are not perfect", i will strongly promote to answer in details the questions i mentionned before deciding 2.8 to be in fact 3.0. >>>> >>>> Then here is the two elements that are probably the biggest things in the roadmap for 3.x versions : >>>> - going social (workspaces in xem, twitter like app, page stats for the user, etc.) >>>> - going to be an easy place to develop in (extension manager of course, but also documentation for dummies and a first app like "app within minute" proposed by guillaume and strongly needed by our front team) >>>> >>>> Is there a consensus on this list ? Then what should be the "demo" features we could present to be consistent for a 3.0 release ? >>> Again this is not the topic of this mail. You're talking about deciding what's in for 4.0 when this mail is about deciding the 3.0 release. >>> >>> Thanks >>> -Vincent >>> >>>> Best >>>> >>>> >>>> >>>> On 1 nov. 2010, at 09:23, Vincent Massol<vincent(a)massol.net> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it. >>>>> >>>>> As Sergiu I believe we need a XE 3.0 ASAP for the following reasons: >>>>> >>>>> - it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year >>>>> - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling >>>>> - it's good for open source marketing >>>>> >>>>> Before being able to release XE 3.0 I think: >>>>> >>>>> - XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) >>>>> - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: >>>>> -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. >>>>> -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. >>>>> -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) >>>>> -- UI finishing touches >>>>> -- Some additional Security and Performance improvements if possible >>>>> -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) >>>>> - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011) >>>>> >>>>> Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now. >>>>> >>>>> Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect. >>>>> >>>>> WDYT? >>>>> >>>>> Thanks >>>>> -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

13 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2010