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?
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.
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).
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<vincent(a)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