1 Nov
2010
1 Nov
'10
9:23 a.m.
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
1 Nov
1 Nov
9:44 a.m.
On 11/01/2010 04:23 AM, Vincent Massol 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
I don't really feel the same way but I don't have a strong opinion about it.
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)
Since it's a major version, my question is what old api should we break?
I have deprecated a number of functions in xwiki-core, (especially in XWikiHibernateStore)
which are
unused and we can consider removing, still I think there should be more deprecations for
2.7 and
more removals.
WDYT?
Caleb
- 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:50 p.m.
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 ?
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 ?
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:22 p.m.
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
6:05 p.m.
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:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:02 p.m.
+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 <ludovic(a)xwiki.com> 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:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
<ludovic.vcf>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:14 p.m.
On Mon, Nov 1, 2010 at 7:02 PM, Gregory GUENEAU <ggueneau(a)me.com> 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 think Ludo meant to give meaningful names, like "Social" or
"Developer Tools" for the major cycles. Of course that does not
prevent us to have "cooler" code name for the minor versions (what
Ludo calls "subname").
I like the idea overall, but I think their is a major drawback of
never releasing a 3.0 or a 4.0, is that people who don't upgrade often
never know when they can best upgrade. Unless maybe we say in the
notes "This release 2.7 will be the last major release of the 2.x
cycle", but that's less explicit.
I'm 0 with the idea right now.
On 1 nov. 2010, at 18:05, Ludovic Dubost <ludovic(a)xwiki.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Nov 1, 2010, at 12:50 PM, Gregory GUENEAU
wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
<ludovic.vcf>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:20 p.m.
On Mon, Nov 1, 2010 at 7:02 PM, Gregory
GUENEAU<ggueneau(a)me.com> wrote:
Right, I think it would be better if the cycle name is expressive of our
goal. If it's not directly understandable, at least being a symbol.
In any case we can have development code names also.
+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 think Ludo meant to give meaningful
names, like "Social" or
"Developer Tools" for the major cycles. Of course that does not
prevent us to have "cooler" code name for the minor versions (what
Ludo calls "subname"). I like the idea overall, but I think their is a major
drawback of
never releasing a 3.0 or a 4.0, is that people who don't upgrade often
never know when they can best upgrade. Unless maybe we say in the
notes "This release 2.7 will be the last major release of the 2.x
cycle", but that's less explicit.
This is already a problem and it's
not very obvious that .0 is the best
release. In this industry it's always been the worst one.
That's where we need to be a bit more talkative about the "cycle" notion
and make understand that it's best to upgrade at the end of a cycle.
Also we could try to use a code name for the last release. Maybe even
for some intermedially ones.
We could use codes like:
- GA (General Availability)
- Gold (which allows to also say Bronze for the early releases and
Silver for the intermediary ones)
- RTM (Release to Manufacturing)
Ludovic
I'm 0 with the idea right now.
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On 1 nov. 2010, at 18:05, Ludovic Dubost<ludovic(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
8:38 p.m.
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<ludovic(a)xwiki.com> 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<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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
3 Nov
3 Nov
9:51 a.m.
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 <sergiu(a)xwiki.com> 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<ludovic(a)xwiki.com> 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<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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2 Nov
2 Nov
12:06 a.m.
-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<ludovic(a)xwiki.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Nov 1, 2010, at 12:50 PM, Gregory GUENEAU
wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
<ludovic.vcf>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:37 a.m.
Not a big fan of the alcohol names.
That said +1 to the idea of seperating the xwiki-platform version numbering from the
branded name. I
like the thought that the decision whether to go to 3.0 or 2.10 has no marketing
pressure.
As far as names I favor something less well known. Everyone knows that a Mojito is a
drink, Fermi in
the other hand is a little known physicist and the brand name of a video card
architecture. To know
of him is, for many, like membership in an exclusive club. I would lean toward rare
chemicals like
cesium or little known researchers or philosophers such as Babbage (
http://en.wikipedia.org/wiki/Charles_Babbage )
Whatever the choice I think it should be made carefully to somehow reflect the vision of
XWiki and
the current state of the code.
Caleb
PS. I'm not a marketer ;)
On 11/01/2010 02: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 <ludovic(a)xwiki.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Nov 1, 2010, at 12:50 PM, Gregory GUENEAU
wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
<ludovic.vcf>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:56 a.m.
New subject: [xwiki-devs] Release Version Numbering Strategy (was Re: [Proposal] XE 3.0 and Roadmap leading to it)
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
2:03 p.m.
New subject: [xwiki-devs] Release Version Numbering Strategy (was Re: [Proposal] XE 3.0 and Roadmap leading to it)
Le 02/11/10 08:56, Vincent Massol a écrit :
Hi Ludovic,
On Nov 1, 2010, at 6:05 PM, Ludovic Dubost wrote:
I don't think this approaches skips a version. Since
the name we should
put in front is "Release 1" and not 3.0 or 3.1.
The number is only there for the technical aspect but from a marketing
pov it's "Release 1" "Release 2".
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?
Well there is still an issue which is to move to 3.0 without setting the
story about what the 3.x cycle will be. This is the important task that
we have to do.
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).
Solution 2 and
3 loose the benefit of showing the world that XWiki has
made a lot of progress. This is one of the big objectives of the main
version change.
I'm still for the idea of not having a .0 at all and calling the last
2.x the RTM or Gold version.
XWiki Enterprise 2.7 RTM or XWiki Enterprise 2.7 Gold
And start with 3.1 with a goal for the 3.x cycle and new features
already in the pipe.
And I'm -1 for releasing a 3.0 that does not show any path for the 3.x
cycle.
Ludovic
Thanks
-Vincent
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Nov
4 Nov
12:51 p.m.
New subject: [xwiki-devs] Release Version Numbering Strategy (was Re: [Proposal] XE 3.0 and Roadmap leading to it)
Le 02/11/10 14:03, Ludovic Dubost a écrit :
Le 02/11/10 08:56, Vincent Massol a écrit :
To clarify my position, following a discussion with Vincent for whom it
seemed it was not clear.
I'm not saying that I'm oposing to make a release early next year called
3.0. I'm just saying that it NEEDS to come with a path for the 3.x cycle
that needs to be discussed before the official release and that is ready
and communicated when we release the 3.0.
This would allow to communicate that 3.0 is a big achievement with this
and this in it, and that the XWiki community has also layout out the
following priorities for 2011.
Ludovic
Hi Ludovic,
On Nov 1, 2010, at 6:05 PM, Ludovic Dubost wrote:
I don't think this approaches skips a version. Since the
name we
should put in front is "Release 1" and not 3.0 or 3.1.
The number is only there for the technical aspect but from a marketing
pov it's "Release 1" "Release 2".
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?
Well there is still an issue which is to move to 3.0 without setting
the story about what the 3.x cycle will be. This is the important task
that we have to do.
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).
Solution 2 and 3 loose the benefit of showing the world that
XWiki has
made a lot of progress. This is one of the big objectives of the main
version change.
I'm still for the idea of not having a .0 at all and calling the last
2.x the RTM or Gold version.
XWiki Enterprise 2.7 RTM or XWiki Enterprise 2.7 Gold
And start with 3.1 with a goal for the 3.x cycle and new features
already in the pipe.
And I'm -1 for releasing a 3.0 that does not show any path for the 3.x
cycle.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3 Nov
3 Nov
9:57 a.m.
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?
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4 Nov
4 Nov
1:05 p.m.
Le 03/11/10 09:57, Sergiu Dumitriu a écrit :
On 11/01/2010 12:50 PM, Gregory GUENEAU wrote:
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
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?
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?
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
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
1 Nov
1 Nov
1:49 p.m.
Hi all,
On Mon, Nov 1, 2010 at 9:23 AM, 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)
I would like to introduce some enhancements and a UI redesign of the
auto suggest feature + a "live search" module on top of the default
search-box that provides typed results as you type.
I will send a separate email with more information about this module
and a plan proposal to get there by 2.7 / 3.0
- 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?
+1 for the overall plan
Jerome.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2 Nov
2 Nov
2:42 p.m.
On Mon, Nov 1, 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.
A non interactive (without any conflict resolution UI) one should be
possible yes. But no time to refactor the current importer and it will
only be a transition based on old model API since the real new xar
handler will need new model to be complete.
-- 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5065
days inactive
5068
days old
18 comments
10 participants
participants (10)
-
Caleb James DeLisle -
Gregory GUENEAU -
Jerome Velociter -
Jerome Velociter -
Ludovic Dubost -
Raluca Stavro -
Sergiu Dumitriu -
Sorin Burjan -
Thomas Mortagne -
Vincent Massol