Re: [xwiki-users] [xwiki-devs] [Proposal] XE 3.0 and Roadmap leading to it
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<[email protected]> wrote:
Hi everyone,
Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it.
As Sergiu I believe we need a XE 3.0 ASAP for the following reasons:
- it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing
Before being able to release XE 3.0 I think:
- XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011)
Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now.
Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect.
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi! Sergiu Dumitriu wrote:
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?
I don't know if I must consider myself in Gregory's educated or uneducated groups, but I really feel myself us included in Sergiu's users category that try to follow software development. I've two main reasons to do that: 1. I try to find solutions for I want to do with our team mates as far as possible 2. I would eventually like to somehow contribute to XWiki development. Being in that situation, it doesn't matter to me if what is coming next is a 2.x release, or a 3.0 one. What I would like to have is a clear idea about what must be able to get working in a given major release. And, if it does not work, to understand why. Let me put three examples: 1. PDF styling (recently fixed by Sergiu; I guess this relates with the new rendering architecture) 2. Lucene indexing 3. Database List and Database Tree property types All three features have been included time ago enough as considering them stable. Am I wrong? I am still not able to know if I must be able to get these three features working, let's say, in a XE 2.5 installation. Or what kind of software I must use, I mean, database and application/servlet server I must use to guarantee "my" users that they will be able to index their contents and use the very nice Lucene features to find contents in attachments. Or search contents in document title. Or whatever you know Lucene is able to do. Similar comments could be done concerning points 1) and 3) Thus, I guess this "stabilization work" you speak about must deal with this issues. Mustn't it? We want "clean" code and a clear idea about what we can do, and what we can't. If this work leads to a 2.x release, or to a 3.0 is not an important decision from my point of view. But, I must insist, I'm a contaminated user! I try to follow all discussions and get an idea, as clear as my skills allow me, about how XWiki evolves. If I think in my own experience using commercial or open source software, as Ludovic said, I would never expect a x.0 release to be particularly stable. I can see it as a final point for the evolution of a x series, but something that has not been tested enough in field work as to expect it will be bug free. In this sense, I think that it will be clearer for me to get a 2.y Gold, GA, or RTM. with a far clear document saying me what I could expect and in what conditions. I know releases notes do that job. Well, something as Gold Release Notes will be welcome! One final remark: more than understanding the general release schema, what is really stopping some users to update more frequently is the update process by itself. I'm not saying it is difficult in itself, but is a bit dangerous. As Vincent recently propose in the devs list for the release process, I do think that a similar work must be done with the upgrade (and to add an entry here http://platform.xwiki.org/xwiki/bin/view/AdminGuide/) and backup processes (I know this http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Backup). Thanks for your work and for sharing this discussion with the community!
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<[email protected]> wrote:
Hi everyone,
Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it.
As Sergiu I believe we need a XE 3.0 ASAP for the following reasons:
- it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing
Before being able to release XE 3.0 I think:
- XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011)
Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now.
Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect.
WDYT?
Thanks -Vincent
-- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems
[Ricardo Rodriguez] eBioTIC. wrote:
Hi!
Sergiu Dumitriu wrote:
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?
I don't know if I must consider myself in Gregory's educated or uneducated groups, but I really feel myself us included in Sergiu's users category that try to follow software development. I've two main reasons to do that:
1. I try to find solutions for I want to do with our team mates as far as possible 2. I would eventually like to somehow contribute to XWiki development.
Being in that situation, it doesn't matter to me if what is coming next is a 2.x release, or a 3.0 one. What I would like to have is a clear idea about what must be able to get working in a given major release. And, if it does not work, to understand why.
Let me put three examples:
1. PDF styling (recently fixed by Sergiu; I guess this relates with the new rendering architecture) 2. Lucene indexing 3. Database List and Database Tree property types
All three features have been included time ago enough as considering them stable. Am I wrong? I am still not able to know if I must be able to get these three features working, let's say, in a XE 2.5 installation. Or what kind of software I must use, I mean, database and application/servlet server I must use to guarantee "my" users that they will be able to index their contents and use the very nice Lucene features to find contents in attachments. Or search contents in document title. Or whatever you know Lucene is able to do. Similar comments could be done concerning points 1) and 3)
Thus, I guess this "stabilization work" you speak about must deal with this issues. Mustn't it? We want "clean" code and a clear idea about what we can do, and what we can't. If this work leads to a 2.x release, or to a 3.0 is not an important decision from my point of view. But, I must insist, I'm a contaminated user! I try to follow all discussions and get an idea, as clear as my skills allow me, about how XWiki evolves.
If I think in my own experience using commercial or open source software, as Ludovic said, I would never expect a x.0 release to be particularly stable. I can see it as a final point for the evolution of a x series, but something that has not been tested enough in field work as to expect it will be bug free. In this sense, I think that it will be clearer for me to get a 2.y Gold, GA, or RTM. with a far clear document saying me what I could expect and in what conditions. I know releases notes do that job. Well, something as Gold Release Notes will be welcome!
One final remark: more than understanding the general release schema, what is really stopping some users to update more frequently is the update process by itself. I'm not saying it is difficult in itself, but is a bit dangerous. As Vincent recently propose in the devs list for the release process, I do think that a similar work must be done with the upgrade (and to add an entry here http://platform.xwiki.org/xwiki/bin/view/AdminGuide/)
I should add this link here... http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradinga... Sorry!
and backup processes (I know this http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Backup).
Thanks for your work and for sharing this discussion with the community!
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<[email protected]> wrote:
Hi everyone,
Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it.
As Sergiu I believe we need a XE 3.0 ASAP for the following reasons:
- it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing
Before being able to release XE 3.0 I think:
- XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011)
Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now.
Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect.
WDYT?
Thanks -Vincent
-- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems
Le 03/11/10 09:57, Sergiu Dumitriu a écrit :
On 11/01/2010 12:50 PM, Gregory GUENEAU wrote:
Hi everyone,
I am +1 to make stabilization work, on a couple of releases I am +1 to have soon a 3.0 release And i am +1 on the content vincent propose
But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family.
Therefore : - do we consider a january 2011 release to be stable enough ? - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? - do we have a clear consensus short list of features that show the path of 3.x family ? - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? From the committers' point of view, it makes perfect sense for 3.0 to be the culmination of the 2.x releases, but I'm not sure the users understand this as well, so I'm extending the question to the users list.
Traditionally, proprietary software is developed behind the curtains, and it's normal to have one big release every two years, with lots of new features and some bugs which get fixed in subsequent bugfix releases. Marketing comes mostly from the proprietary software world, so from a marketing point of view, this is the "normal" way releases work.
In the open source world, since the development is done in the open, it doesn't make sense to stash code away in a repository and only release it once every two years. Still, most big projects use a release versioning scheme similar to the proprietary products, but with a slight difference which deeply changes the meaning. While proprietary products use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, 5.5), open source usually has 3 numbers in its versions, with the following meanings:
The first number changes rarely, and when it does, it signals a critical change, like a complete rewrite of the codebase, a change of paradigm, or major new features. The second number is the one that actually identifies a release. The third number is the bugfix version. So, when we say that PHP 5.3.2 was released, we actually say that version 3 of PHP5, which is a different thing than PHP4, has been released again, giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw its first bugfix release.
Another tendency is for open source software to linger towards a major release. For example, lots of software have a lot of releases before 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows that 0.x comes before 1.0, and it's not just a bugfix version of an imaginary 0.0 release.
A different topic is that of agile development, with very short releases (2-3 weeks) for which traditional version number make no sense, since such a product would reach version 42 in a couple of years. Either an identifier, such as the SCM version number is used, or a continuous counter (v1.42) is used. Since the software evolves in a fluid manner, without a "breakthrough" version coming out of the regular releases, a "major" version is released when the current features are stable and they mix well together in a coherent product. Since releases come so frequently, it's normal for users to be split into two categories: those that follow the releases and know how the software is evolving, and those that only monitor the major releases, and which see all the continuous improvements at once.
While XWiki Enterprise is used in the enterprise environment, and it is backed by commercial companies, it is a true open source project, following an open source release model, so I don't think that a proprietary product release scheme is suited.
Our development/release style is closer to the agile development practice, albeit with mixed release types. In the future, once the core is more stable than it is now, we'd like to move even closer to a full agile release process, with 2-3 weeks between final releases. Thus, I believe that the last release versioning strategy is the best for XWiki Enterprise.
Note that we're already using this strategy in a more obvious way for smaller modules (applications, skins, tools), where we do have 1.32 as a stable version number.
Also note that although 1.9 was followed by 2.0, this was just a coincidence, and not a natural version evolution, since we also felt that the code was mature enough to receive a major number bump, but it could just as well have been followed by a 1.10.
So, there are two different opinions here. One that 3.0 should present the groundwork/roadmap for the following 3.x releases, and one that 3.0 should be the culmination of the work done so far on the 2.x releases.
The committers (with the exception of Ludovic) believe that the latter is the better one, and it is in accordance with what we've been doing so far. What do our users think?
Hi, I'd like to point out that it's not that I'm against a 3.0 being the final release of the 2.x cycle, but that there is an oddity of doing that, and that I proposed an alternate scheme that does not say 3.0 is the first of the new cycle, but that actually removes the notion of 3.0 by using a "text" naming scheme instead of a numbering scheme and that the first release would be called XWiki RELEASENAME Release 1 (instead of 3.0). And in order to know which one is the final one to use "RTM" or "Gold" for the last release of a cycle. This is just a proposal to try to avoid the .0 oddity where in the software world .0 are usually the less finished release of a cycle. Finally as Ricardo, once you understand XWiki the numbering scheme is not that important and I agree that what you want to know is wether a feature is BETA or STABLE in each release whatever the numbering is. The main usage of the final version is to improve communication around it (press likes articles about new major versions). For that I agree that .0 is always going to be better. Ludovic
As a final remark, the XWiki Open Source projects are governed by the committers, so in the end the decision lies in the hands of the developers, but we're always open to the larger community. If no consensus is reached about when to release 3.0, we will continue releasing 2.x versions.
What do XWiki users think? Is 3.0 as a culmination of the 2.x releases, with no major new features besides what 2.5 already provides, something the community expects?
We have to make 100% sure our message will be understood by market. We are now in the Gartner magic quadrant and will increase our visibility outside the opensource community. In a world where new release number families means : "we show the path of the future of this software, even if the features we present are not perfect", i will strongly promote to answer in details the questions i mentionned before deciding 2.8 to be in fact 3.0. XWiki SAS is in the Gartner report, as a vendor. The XWiki Enterprise project is not in that report. I think the marketing direction that Gregory and Ludovic are supporting is better suited for the company offerings.
Then here is the two elements that are probably the biggest things in the roadmap for 3.x versions : - going social (workspaces in xem, twitter like app, page stats for the user, etc.) - going to be an easy place to develop in (extension manager of course, but also documentation for dummies and a first app like "app within minute" proposed by guillaume and strongly needed by our front team)
Is there a consensus on this list ? Then what should be the "demo" features we could present to be consistent for a 3.0 release ? Yes, these should be central in the future 3.x releases, but not in 3.0, which should be as stable as possible, without any "demo" features.
Best
On 1 nov. 2010, at 09:23, Vincent Massol<[email protected]> wrote:
Hi everyone,
Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it.
As Sergiu I believe we need a XE 3.0 ASAP for the following reasons:
- it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing
Before being able to release XE 3.0 I think:
- XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011)
Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now.
Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect.
WDYT?
Thanks -Vincent
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, Just want to share my thought, I've worked for 15 years in the software domain, and I'm used to release numbers. For me, a 3.0 release is not stable. Have a nice day. Maxime 2010/11/4 Ludovic Dubost <[email protected]>
Le 03/11/10 09:57, Sergiu Dumitriu a écrit :
On 11/01/2010 12:50 PM, Gregory GUENEAU wrote:
Hi everyone,
I am +1 to make stabilization work, on a couple of releases I am +1 to have soon a 3.0 release And i am +1 on the content vincent propose
But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family.
Therefore : - do we consider a january 2011 release to be stable enough ? - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? - do we have a clear consensus short list of features that show the path of 3.x family ? - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? From the committers' point of view, it makes perfect sense for 3.0 to be the culmination of the 2.x releases, but I'm not sure the users understand this as well, so I'm extending the question to the users list.
Traditionally, proprietary software is developed behind the curtains, and it's normal to have one big release every two years, with lots of new features and some bugs which get fixed in subsequent bugfix releases. Marketing comes mostly from the proprietary software world, so from a marketing point of view, this is the "normal" way releases work.
In the open source world, since the development is done in the open, it doesn't make sense to stash code away in a repository and only release it once every two years. Still, most big projects use a release versioning scheme similar to the proprietary products, but with a slight difference which deeply changes the meaning. While proprietary products use only a number (3, 8, 2010...), with eventual bugfixes versions (SP2, 5.5), open source usually has 3 numbers in its versions, with the following meanings:
The first number changes rarely, and when it does, it signals a critical change, like a complete rewrite of the codebase, a change of paradigm, or major new features. The second number is the one that actually identifies a release. The third number is the bugfix version. So, when we say that PHP 5.3.2 was released, we actually say that version 3 of PHP5, which is a different thing than PHP4, has been released again, giving the second bugfix release. KDE 4.5.1 means version 5 of KDE4 saw its first bugfix release.
Another tendency is for open source software to linger towards a major release. For example, lots of software have a lot of releases before 1.0, going nearer and nearer: 0.6, 0.9, 0.9.9... And everybody knows that 0.x comes before 1.0, and it's not just a bugfix version of an imaginary 0.0 release.
A different topic is that of agile development, with very short releases (2-3 weeks) for which traditional version number make no sense, since such a product would reach version 42 in a couple of years. Either an identifier, such as the SCM version number is used, or a continuous counter (v1.42) is used. Since the software evolves in a fluid manner, without a "breakthrough" version coming out of the regular releases, a "major" version is released when the current features are stable and they mix well together in a coherent product. Since releases come so frequently, it's normal for users to be split into two categories: those that follow the releases and know how the software is evolving, and those that only monitor the major releases, and which see all the continuous improvements at once.
While XWiki Enterprise is used in the enterprise environment, and it is backed by commercial companies, it is a true open source project, following an open source release model, so I don't think that a proprietary product release scheme is suited.
Our development/release style is closer to the agile development practice, albeit with mixed release types. In the future, once the core is more stable than it is now, we'd like to move even closer to a full agile release process, with 2-3 weeks between final releases. Thus, I believe that the last release versioning strategy is the best for XWiki Enterprise.
Note that we're already using this strategy in a more obvious way for smaller modules (applications, skins, tools), where we do have 1.32 as a stable version number.
Also note that although 1.9 was followed by 2.0, this was just a coincidence, and not a natural version evolution, since we also felt that the code was mature enough to receive a major number bump, but it could just as well have been followed by a 1.10.
So, there are two different opinions here. One that 3.0 should present the groundwork/roadmap for the following 3.x releases, and one that 3.0 should be the culmination of the work done so far on the 2.x releases.
The committers (with the exception of Ludovic) believe that the latter is the better one, and it is in accordance with what we've been doing so far. What do our users think?
Hi,
I'd like to point out that it's not that I'm against a 3.0 being the final release of the 2.x cycle, but that there is an oddity of doing that, and that I proposed an alternate scheme that does not say 3.0 is the first of the new cycle, but that actually removes the notion of 3.0 by using a "text" naming scheme instead of a numbering scheme and that the first release would be called XWiki RELEASENAME Release 1 (instead of 3.0). And in order to know which one is the final one to use "RTM" or "Gold" for the last release of a cycle.
This is just a proposal to try to avoid the .0 oddity where in the software world .0 are usually the less finished release of a cycle.
Finally as Ricardo, once you understand XWiki the numbering scheme is not that important and I agree that what you want to know is wether a feature is BETA or STABLE in each release whatever the numbering is. The main usage of the final version is to improve communication around it (press likes articles about new major versions). For that I agree that .0 is always going to be better.
Ludovic
As a final remark, the XWiki Open Source projects are governed by the committers, so in the end the decision lies in the hands of the developers, but we're always open to the larger community. If no consensus is reached about when to release 3.0, we will continue releasing 2.x versions.
What do XWiki users think? Is 3.0 as a culmination of the 2.x releases, with no major new features besides what 2.5 already provides, something the community expects?
We have to make 100% sure our message will be understood by market. We are now in the Gartner magic quadrant and will increase our visibility outside the opensource community. In a world where new release number families means : "we show the path of the future of this software, even if the features we present are not perfect", i will strongly promote to answer in details the questions i mentionned before deciding 2.8 to be in fact 3.0. XWiki SAS is in the Gartner report, as a vendor. The XWiki Enterprise project is not in that report. I think the marketing direction that Gregory and Ludovic are supporting is better suited for the company offerings.
Then here is the two elements that are probably the biggest things in the roadmap for 3.x versions : - going social (workspaces in xem, twitter like app, page stats for the user, etc.) - going to be an easy place to develop in (extension manager of course, but also documentation for dummies and a first app like "app within minute" proposed by guillaume and strongly needed by our front team)
Is there a consensus on this list ? Then what should be the "demo" features we could present to be consistent for a 3.0 release ? Yes, these should be central in the future 3.x releases, but not in 3.0, which should be as stable as possible, without any "demo" features.
Best
On 1 nov. 2010, at 09:23, Vincent Massol<[email protected]> wrote:
Hi everyone,
Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it.
As Sergiu I believe we need a XE 3.0 ASAP for the following reasons:
- it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling - it's good for open source marketing
Before being able to release XE 3.0 I think:
- XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) -- UI finishing touches -- Some additional Security and Performance improvements if possible -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011)
Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now.
Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect.
WDYT?
Thanks -Vincent
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
I have not been in the industry as long as some here, nor have I worked on as many projects, etc, but I have been a long time user of software, and well as written my own. The way I see things are (Major Revision).(Minor Revision).(Fix) there are sometimes different schema perhaps for daily builds there will be a fourth and fifth number, providing a Julian date and/or iteration. The true question is what do users see as revision changes. Because that is really what matters. Developers don't care as long as they can identify and follow the schema, they don't care how its named. The way that I see a Major Revision (of course everything BETA before release) would incorporate stable things from all previous releases, a change in the code base that introduced new mostly stable functionality, beyond a simple add in. For example the full implementation of the query manager, or a direct syntax from page edit, to object property; or the addition of support for RDF/OWL in the language itself. All of this would be something I would consider a major release. A Minor release is small additions to the current framework, without a major shift in how the code works. Added functionality to existing plugins, or tweeks in how they behave. Fix is patches or bug fixes, that dont add to the code base in functionality, or but correct behavior in the code to preform as expected. I Think this schema is often the most adapted, even in Agile environments, open source and propritery software as whole. I would think that this is how one should move foward, as well as it increasing the understanding of what each release would mean, and how with each release its evovled. It is important to note that there can be several releases in the dev environment that the user never sees. So for example going from 2.4.1263 to 2.5.3625, could be seen by the user while there were several progressive builds behind the scenes that brought 2.5 to a stable place. just my two cents Martin Bryant Modus Operandi -- View this message in context: http://xwiki.475771.n2.nabble.com/Re-xwiki-devs-Proposal-XE-3-0-and-Roadmap-... Sent from the XWiki- Users mailing list archive at Nabble.com.
participants (5)
-
[Ricardo Rodriguez] eBioTIC. -
Ludovic Dubost -
Maxime Mathieu -
mbryant -
Sergiu Dumitriu