4 Nov
2010
4 Nov
'10
3:34 p.m.
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 <ludovic(a)xwiki.com>
Le 03/11/10 09:57, Sergiu Dumitriu a écrit :
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
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<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