Hi, Just want to share my thought, I've worked for 15 years in the software domain, and I'm used to release numbers. For me, a 3.0 release is not stable.
Have a nice day. Maxime 2010/11/4 Ludovic Dubost <[email protected]> > Le 03/11/10 09:57, Sergiu Dumitriu a écrit : > > 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? > > > Hi, > > I'd like to point out that it's not that I'm against a 3.0 being the > final release of the 2.x cycle, but that there is an oddity of doing > that, and that I proposed an alternate scheme that does not say 3.0 is > the first of the new cycle, but that actually removes the notion of 3.0 > by using a "text" naming scheme instead of a numbering scheme and that > the first release would be called XWiki RELEASENAME Release 1 (instead > of 3.0). And in order to know which one is the final one to use "RTM" or > "Gold" for the last release of a cycle. > > This is just a proposal to try to avoid the .0 oddity where in the > software world .0 are usually the less finished release of a cycle. > > Finally as Ricardo, once you understand XWiki the numbering scheme is > not that important and I agree that what you want to know is wether a > feature is BETA or STABLE in each release whatever the numbering is. The > main usage of the final version is to improve communication around it > (press likes articles about new major versions). For that I agree that > .0 is always going to be better. > > Ludovic > > > 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? > > > > > >> 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<[email protected]> 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 > > > > > -- > Ludovic Dubost > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > > > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
