-1 for cocktail names. Reason: 1. We produce enterprise software. 2.A version called : Vodka, Heiniken, White Russian, etc .. doesn't have a resonance. At least not a serious one. 3.Cannonical/Ubuntu use always 2 words for release, one an animal name, the other a funny characteristic.
As a suggestion, If we really want names for releases, we can use something with a little bit of IT, Enterprise, Social Web, etc. We need something that has something serious and dynamic in it. Regards, Sorin B. On 11/1/2010 8:02 PM, Gregory GUENEAU wrote: > +1 > > About the release naming, jerome proposed cocktail names, and this is quite a > good idea, if we are sure to give this image > About that i am 0- > The idea i like is to associate exotic name to the quite "cold" name of XWiki > > If we vote for cocktail name, i like ludo's proposal to have alcool / > cocktail name > > Exemple : XWiki Rhum release 1 : Mojito > See here, we might suffer a lack of credibility with this naming but we can > live with it (of course if we do not get all alchoolics) > > > > On 1 nov. 2010, at 18:05, Ludovic Dubost<[email protected]> 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. >> >> 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<[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 >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> -- >> Ludovic Dubost >> Blog: http://blog.ludovic.org/ >> XWiki: http://www.xwiki.com >> Skype: ldubost GTalk: ldubost >> >> <ludovic.vcf> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
