I'm sure that you can find something better than cocktail names. So, -1 for such names.
Raluca. On Mon, Nov 1, 2010 at 9:38 PM, Sergiu Dumitriu <[email protected]> wrote: > On 11/01/2010 07: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) > > I'd have to exert my veto right against alcoholic beverages. > > > 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 > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
