Hi vincent, On 2 nov. 2010, at 08:56, Vincent Massol <[email protected]> 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<[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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
