[Ricardo Rodriguez] eBioTIC. wrote: > Hi! > > Sergiu Dumitriu wrote: > >> On 11/01/2010 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 ? >>> - stabilization work wouldn'it be leading then to the last 2.x version >>> instead of the first 3.x family version ? >>> - is there behind it a consensus on what we will concentrate our effort in >>> 3.x versions ? I mean thematics we can talk about. >>> - therefore, are we in a situation where we can vote on the global >>> thematics we will develop in 3.x releases ? >>> - do we have a clear consensus short list of features that show the path of >>> 3.x family ? >>> - 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 ? >>> - do educated people care this much about release number, that we >>> absolutely have to release a 3.0 with the content presented below ? >>> >>> >> From the committers' point of view, it makes perfect sense for 3.0 to >> be the culmination of the 2.x releases, but I'm not sure the users >> understand this as well, so I'm extending the question to the users list. >> >> Traditionally, proprietary software is developed behind the curtains, >> and it's normal to have one big release every two years, with lots of >> new features and some bugs which get fixed in subsequent bugfix >> releases. Marketing comes mostly from the proprietary software world, so >> from a marketing point of view, this is the "normal" way releases work. >> >> In the open source world, since the development is done in the open, it >> doesn't make sense to stash code away in a repository and only release >> it once every two years. Still, most big projects use a release >> versioning scheme similar to the proprietary products, but with a slight >> difference which deeply changes the meaning. While proprietary products >> use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, >> 5.5), open source usually has 3 numbers in its versions, with the >> following meanings: >> >> The first number changes rarely, and when it does, it signals a critical >> change, like a complete rewrite of the codebase, a change of paradigm, >> or major new features. The second number is the one that actually >> identifies a release. The third number is the bugfix version. So, when >> we say that PHP 5.3.2 was released, we actually say that version 3 of >> PHP5, which is a different thing than PHP4, has been released again, >> giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw >> its first bugfix release. >> >> Another tendency is for open source software to linger towards a major >> release. For example, lots of software have a lot of releases before >> 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows >> that 0.x comes before 1.0, and it's not just a bugfix version of an >> imaginary 0.0 release. >> >> A different topic is that of agile development, with very short releases >> (2-3 weeks) for which traditional version number make no sense, since >> such a product would reach version 42 in a couple of years. Either an >> identifier, such as the SCM version number is used, or a continuous >> counter (v1.42) is used. Since the software evolves in a fluid manner, >> without a "breakthrough" version coming out of the regular releases, a >> "major" version is released when the current features are stable and >> they mix well together in a coherent product. Since releases come so >> frequently, it's normal for users to be split into two categories: those >> that follow the releases and know how the software is evolving, and >> those that only monitor the major releases, and which see all the >> continuous improvements at once. >> >> While XWiki Enterprise is used in the enterprise environment, and it is >> backed by commercial companies, it is a true open source project, >> following an open source release model, so I don't think that a >> proprietary product release scheme is suited. >> >> Our development/release style is closer to the agile development >> practice, albeit with mixed release types. In the future, once the core >> is more stable than it is now, we'd like to move even closer to a full >> agile release process, with 2-3 weeks between final releases. Thus, I >> believe that the last release versioning strategy is the best for XWiki >> Enterprise. >> >> Note that we're already using this strategy in a more obvious way for >> smaller modules (applications, skins, tools), where we do have 1.32 as a >> stable version number. >> >> Also note that although 1.9 was followed by 2.0, this was just a >> coincidence, and not a natural version evolution, since we also felt >> that the code was mature enough to receive a major number bump, but it >> could just as well have been followed by a 1.10. >> >> So, there are two different opinions here. One that 3.0 should present >> the groundwork/roadmap for the following 3.x releases, and one that 3.0 >> should be the culmination of the work done so far on the 2.x releases. >> >> The committers (with the exception of Ludovic) believe that the latter >> is the better one, and it is in accordance with what we've been doing so >> far. What do our users think? >> >> >> As a final remark, the XWiki Open Source projects are governed by the >> committers, so in the end the decision lies in the hands of the >> developers, but we're always open to the larger community. If no >> consensus is reached about when to release 3.0, we will continue >> releasing 2.x versions. >> >> >> What do XWiki users think? Is 3.0 as a culmination of the 2.x releases, >> with no major new features besides what 2.5 already provides, something >> the community expects? >> >> >> > > I don't know if I must consider myself in Gregory's educated or > uneducated groups, but I really feel myself us included in Sergiu's > users category that try to follow software development. I've two main > reasons to do that: > > 1. I try to find solutions for I want to do with our team mates as far > as possible > 2. I would eventually like to somehow contribute to XWiki development. > > Being in that situation, it doesn't matter to me if what is coming next > is a 2.x release, or a 3.0 one. What I would like to have is a clear > idea about what must be able to get working in a given major release. > And, if it does not work, to understand why. > > Let me put three examples: > > 1. PDF styling (recently fixed by Sergiu; I guess this relates with the > new rendering architecture) > 2. Lucene indexing > 3. Database List and Database Tree property types > > All three features have been included time ago enough as considering > them stable. Am I wrong? I am still not able to know if I must be able > to get these three features working, let's say, in a XE 2.5 > installation. Or what kind of software I must use, I mean, database and > application/servlet server I must use to guarantee "my" users that they > will be able to index their contents and use the very nice Lucene > features to find contents in attachments. Or search contents in document > title. Or whatever you know Lucene is able to do. Similar comments could > be done concerning points 1) and 3) > > Thus, I guess this "stabilization work" you speak about must deal with > this issues. Mustn't it? We want "clean" code and a clear idea about > what we can do, and what we can't. If this work leads to a 2.x release, > or to a 3.0 is not an important decision from my point of view. But, I > must insist, I'm a contaminated user! I try to follow all discussions > and get an idea, as clear as my skills allow me, about how XWiki evolves. > > If I think in my own experience using commercial or open source > software, as Ludovic said, I would never expect a x.0 release to be > particularly stable. I can see it as a final point for the evolution of > a x series, but something that has not been tested enough in field work > as to expect it will be bug free. In this sense, I think that it will be > clearer for me to get a 2.y Gold, GA, or RTM. with a far clear document > saying me what I could expect and in what conditions. I know releases > notes do that job. Well, something as Gold Release Notes will be welcome! > > One final remark: more than understanding the general release schema, > what is really stopping some users to update more frequently is the > update process by itself. I'm not saying it is difficult in itself, but > is a bit dangerous. As Vincent recently propose in the devs list for the > release process, I do think that a similar work must be done with the > upgrade (and to add an entry here > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/)
I should add this link here... http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradinganXWikiInstallation Sorry! > and backup > processes (I know this > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Backup). > > Thanks for your work and for sharing this discussion with the community! > >> >> >>> 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. >>> >>> >> XWiki SAS is in the Gartner report, as a vendor. The XWiki Enterprise >> project is not in that report. I think the marketing direction that >> Gregory and Ludovic are supporting is better suited for the company >> offerings. >> >> >> >>> 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 ? >>> >>> >> Yes, these should be central in the future 3.x releases, but not in 3.0, >> which should be as stable as possible, without any "demo" features. >> >> >> >>> Best >>> >>> >>> >>> On 1 nov. 2010, at 09:23, Vincent Massol<vinc...@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 >>>> >>>> >> >> > > -- Ricardo RodrÃguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
