Re: [DISCUSS] next release version? 0.6 or 1.0?
back 2 the topic, please! I'd say we should approach 1.0 NOW. DeltaSpike core and a few other modules is really rock solid already since a year or so. It is also used heavily in production already. There will always be some modules which are not so perfectly mature at times. E.g. if we will add a new module. Thus I already did propose a methology which would fix this shortcoming: We might introduce an 'ample page' which contains the status of each project - stable / ready /in progress You know, the traffic light thingy where green means the module (e.g. deltaspike-core) is stable and the API will not change or we will at least be backward compatible unless we do a major new version. Orange means that the module has been tested and looks good. Whereas red means that the api might change still. What road blockers do we have before 1.0? Please note that there is always something one can do better - but this should not hinder us from releasing until something is really broken. Also the documentation is *not* a show stopper - it is perfectly fine to ship this later as our CMS is completely asynchronous. So what BLOCKERS do you see before I go and press the release button? Like to do that on Wednesday... LieGrue, strub On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote: That’s reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote: Probably because we've become busy with some other projects and priorities :(— Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
Hi can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx stuff? Basically I'm waiting after it for months and this is blocker to be used ATM. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 9:57 GMT+01:00 Mark Struberg strub...@yahoo.de: back 2 the topic, please! I'd say we should approach 1.0 NOW. DeltaSpike core and a few other modules is really rock solid already since a year or so. It is also used heavily in production already. There will always be some modules which are not so perfectly mature at times. E.g. if we will add a new module. Thus I already did propose a methology which would fix this shortcoming: We might introduce an 'ample page' which contains the status of each project - stable / ready /in progress You know, the traffic light thingy where green means the module (e.g. deltaspike-core) is stable and the API will not change or we will at least be backward compatible unless we do a major new version. Orange means that the module has been tested and looks good. Whereas red means that the api might change still. What road blockers do we have before 1.0? Please note that there is always something one can do better - but this should not hinder us from releasing until something is really broken. Also the documentation is *not* a show stopper - it is perfectly fine to ship this later as our CMS is completely asynchronous. So what BLOCKERS do you see before I go and press the release button? Like to do that on Wednesday... LieGrue, strub On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote: That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote: Probably because we've become busy with some other projects and priorities :(-- Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for this :) 2014-02-17 10:10 GMT+01:00 Mark Struberg strub...@yahoo.de: Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix the Tx stuff. In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0. wdyt? LieGrue, strub On Monday, 17 February 2014, 10:06, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx stuff? Basically I'm waiting after it for months and this is blocker to be used ATM. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 9:57 GMT+01:00 Mark Struberg strub...@yahoo.de: back 2 the topic, please! I'd say we should approach 1.0 NOW. DeltaSpike core and a few other modules is really rock solid already since a year or so. It is also used heavily in production already. There will always be some modules which are not so perfectly mature at times. E.g. if we will add a new module. Thus I already did propose a methology which would fix this shortcoming: We might introduce an 'ample page' which contains the status of each project - stable / ready /in progress You know, the traffic light thingy where green means the module (e.g. deltaspike-core) is stable and the API will not change or we will at least be backward compatible unless we do a major new version. Orange means that the module has been tested and looks good. Whereas red means that the api might change still. What road blockers do we have before 1.0? Please note that there is always something one can do better - but this should not hinder us from releasing until something is really broken. Also the documentation is *not* a show stopper - it is perfectly fine to ship this later as our CMS is completely asynchronous. So what BLOCKERS do you see before I go and press the release button? Like to do that on Wednesday... LieGrue, strub On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote: That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote: Probably because we've become busy with some other projects and priorities :(-- Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 Mark 2014-02-17 13:08 GMT+01:00 Ove Ranheim oranh...@gmail.com: +1 for this :) 2014-02-17 10:10 GMT+01:00 Mark Struberg strub...@yahoo.de: Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix the Tx stuff. In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0. wdyt? LieGrue, strub On Monday, 17 February 2014, 10:06, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx stuff? Basically I'm waiting after it for months and this is blocker to be used ATM. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 9:57 GMT+01:00 Mark Struberg strub...@yahoo.de: back 2 the topic, please! I'd say we should approach 1.0 NOW. DeltaSpike core and a few other modules is really rock solid already since a year or so. It is also used heavily in production already. There will always be some modules which are not so perfectly mature at times. E.g. if we will add a new module. Thus I already did propose a methology which would fix this shortcoming: We might introduce an 'ample page' which contains the status of each project - stable / ready /in progress You know, the traffic light thingy where green means the module (e.g. deltaspike-core) is stable and the API will not change or we will at least be backward compatible unless we do a major new version. Orange means that the module has been tested and looks good. Whereas red means that the api might change still. What road blockers do we have before 1.0? Please note that there is always something one can do better - but this should not hinder us from releasing until something is really broken. Also the documentation is *not* a show stopper - it is perfectly fine to ship this later as our CMS is completely asynchronous. So what BLOCKERS do you see before I go and press the release button? Like to do that on Wednesday... LieGrue, strub On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote: That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote: Probably because we've become busy with some other projects and priorities :(-- Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 On Mon, Feb 17, 2014 at 2:10 AM, Mark Struberg strub...@yahoo.de wrote: Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix the Tx stuff. In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0. wdyt? LieGrue, strub On Monday, 17 February 2014, 10:06, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx stuff? Basically I'm waiting after it for months and this is blocker to be used ATM. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 9:57 GMT+01:00 Mark Struberg strub...@yahoo.de: back 2 the topic, please! I'd say we should approach 1.0 NOW. DeltaSpike core and a few other modules is really rock solid already since a year or so. It is also used heavily in production already. There will always be some modules which are not so perfectly mature at times. E.g. if we will add a new module. Thus I already did propose a methology which would fix this shortcoming: We might introduce an 'ample page' which contains the status of each project - stable / ready /in progress You know, the traffic light thingy where green means the module (e.g. deltaspike-core) is stable and the API will not change or we will at least be backward compatible unless we do a major new version. Orange means that the module has been tested and looks good. Whereas red means that the api might change still. What road blockers do we have before 1.0? Please note that there is always something one can do better - but this should not hinder us from releasing until something is really broken. Also the documentation is *not* a show stopper - it is perfectly fine to ship this later as our CMS is completely asynchronous. So what BLOCKERS do you see before I go and press the release button? Like to do that on Wednesday... LieGrue, strub On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote: That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote: Probably because we've become busy with some other projects and priorities :(-- Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
Dear DS team! Two months ago the team discussed a 0.6 release. What is your plan? There are many new great features since 0.5, so what is stopping the DS-team to provide a new release? Looking through the JIRA there are 30 open issues, many of them regards JSF and Tests. I don’t use JSF anymore, so it hurts to be held back by stack-releases. 6 out of 30 are Improvements. 7 are New Features. 1 is a Wish of porting Seam Mail. Cody has discontinued development of Seam Mail, so this issue could probably be Resolved/Won’t fix. If you constrain the release window to only bug fixing it looks like 14 issues should be moved to 0.7. 16 issues are real issues that needs to be decided upon. Would it make sense to elect on some big tickets to get 0.6 out? 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be a success, regular releases is a key factor. It’s been five months since last 0.5 release. regards, ove On 12. nov. 2013, at 16:28, Mark Struberg strub...@yahoo.de wrote: yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 12 November 2013, 16:18 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for 0.6 and 1.0 as the next release after 0.6 2014-02-16 12:40 GMT+01:00 Ove Ranheim oranh...@gmail.com: Dear DS team! Two months ago the team discussed a 0.6 release. What is your plan? There are many new great features since 0.5, so what is stopping the DS-team to provide a new release? Looking through the JIRA there are 30 open issues, many of them regards JSF and Tests. I don't use JSF anymore, so it hurts to be held back by stack-releases. 6 out of 30 are Improvements. 7 are New Features. 1 is a Wish of porting Seam Mail. Cody has discontinued development of Seam Mail, so this issue could probably be Resolved/Won't fix. If you constrain the release window to only bug fixing it looks like 14 issues should be moved to 0.7. 16 issues are real issues that needs to be decided upon. Would it make sense to elect on some big tickets to get 0.6 out? 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be a success, regular releases is a key factor. It's been five months since last 0.5 release. regards, ove On 12. nov. 2013, at 16:28, Mark Struberg strub...@yahoo.de wrote: yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 12 November 2013, 16:18 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard's point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi
Re: [DISCUSS] next release version? 0.6 or 1.0?
Hi Gerhard, Was your point the commit graph or the professional support? I would recognize Apache Software to be an Open Source Foundation. My intent was not identify myself as a customer to shop commercial product support, on something not completed, but to urge the importance of getting sources, compiled binaries (read: i can do that myself), out the door. Not, the professional part of it. I used to be one of the JBoss-ers evangelists (external) and wishes to see the joint efforts agreed on 2+ years ago to become the success on top of CDI, that DS really deserves to become. Cheers, Ove On 16. feb. 2014, at 21:54, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, fyi: i just sent the link for our site. for code+site you can have a look at [1]. regards, gerhard [1] http://s.apache.org/Pov http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 21:27 GMT+01:00 Ove Ranheim oranh...@gmail.com: Mark, when do you plan to get the 1.0 release out? Time is important. Since there's a lot of documentation required, wouldn't this cause further delays? Are we talking about a shippable product in May timeframe, or would we see a release in Feb, possibly in March? I'm a user of DS, but in order to trust CDI/DS and not move towards Spring. This is a big question for me, and I'm sure for many others (and potential) users too. IMO, it's a mistake not keep a tight e.g 12 weekly shippable release. Being Agile is key to success. The project has been running for 25+ months now. Reading through sources and looking at the commit-graph from Gerhard. I think you guys deserve to see an uptake of DS. But, binaries needs to be pushed to central. I'd say: -1 for 1.0 +1 for 0.6. br, ove On 16. feb. 2014, at 16:39, Mark Struberg strub...@yahoo.de wrote: I'd be +1 for 1.0 LieGrue, strub On Sunday, 16 February 2014, 14:52, Nicklas Karlsson nicka...@gmail.com wrote: (the rumors of my demise is somewhat exaggerated ;-) After migrating some applications from Seam 2 to Seam 3 (and then have Seam 3 run out of steam), I recommended migrating to DeltaSpike so I have some interest in DeltaSpike not end up the same way, that would be... professionally embarrassing ;-) Although I'm not obsessed with version numbers, I know several people who are and a 1.0 would certainly attract attention (and hopefully contributors). OTOH, one must be careful not to destroy the reputation of the framework by releasing too early and give a crappy first impression. Even if there are not that many fancy features, if the existing ones are well documented and accompanied by examples, people are usually more forgiving. Having said that, I might be able to contribute some company time on e.g. the JSF module (since we are using that, too). regards, - Nik On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim oranh...@gmail.com wrote: Dear DS team! Two months ago the team discussed a 0.6 release. What is your plan? There are many new great features since 0.5, so what is stopping the DS-team to provide a new release? Looking through the JIRA there are 30 open issues, many of them regards JSF and Tests. I don't use JSF anymore, so it hurts to be held back by stack-releases. 6 out of 30 are Improvements. 7 are New Features. 1 is a Wish of porting Seam Mail. Cody has discontinued development of Seam Mail, so this issue could probably be Resolved/Won't fix. If you constrain the release window to only bug fixing it looks like 14 issues should be moved to 0.7. 16 issues are real issues that needs to be decided upon. Would it make sense to elect on some big tickets to get 0.6 out? 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be a success, regular releases is a key factor. It's been five months since last 0.5 release. regards, ove On 12. nov. 2013, at 16:28, Mark Struberg strub...@yahoo.de wrote: yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 12 November 2013, 16:18 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
Probably because we've become busy with some other projects and priorities :(— Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote: The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com: +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
I think 1.0 sounds great. Improving docs would be the best way to move deltaspike forward imo. My major concern right now is the windowId stuff. I like many want the functionality but struggles with dual ids (windowId dsRid) a loading splash. Would love docs here that covers the different strategies and routes one can take. cheers On 15 November 2013 14:31, Christian Kaltepoth christ...@kaltepoth.dewrote: +1 for releasing 1.0 next -1 for subreleases. This would be very confusing. +1 for improving the documentation before the 1.0 release. This is IMHO more important than examples. 2013/11/11 Romain Manni-Bucau rmannibu...@gmail.com Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: [DISCUSS] next release version? 0.6 or 1.0?
Thomas, you are really welcome to help us with pushing those features. Others as well. LieGrue, strub - Original Message - From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 13 November 2013, 23:51 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @Romain: I understand all your concerns - really! But from the view of CODI users, the current situation is quite disappointing because the most required CODI features are still not available since over a year IMO 1.0 should contain all important features. I would be happy if we could import Gerhards port of the CODI features for a 1.0 and enhance/reimplement the internal stuff later. Anyway, i think DS is currently already quite stable and a 1.0 is really required after this long time. But, as gerhard already stated, a better documentation and examples is really the minimum! I would also take the same version for each module. Its also easier to maintain for the users. 2013/11/13 Cody Lerum cody.le...@gmail.com +1 for a 1.0 when docs are in order. As far as versioning I prefer the same ver for each module. I do dislike potentially having to release the exact same code multiple times just under a different version but I don't know what the alternatives would be. If you have modules with different version numbers it tends to make the users pom very brittle. On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote: FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a table on the website what the maturity of each module is. On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote: Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version
Re: [DISCUSS] next release version? 0.6 or 1.0?
As documentation and quality of examples is critical to promote DeltaSpike project, I will take care of that during next weeks as I will be more available on the project. But first I would like to finalize some issues with Apache Camel CDI Extension running on Karaf (Weld, Webbeans). As Weld 2.1.0.Final is out, we could also move to that version. On Thu, Nov 14, 2013 at 1:17 PM, Mark Struberg strub...@yahoo.de wrote: Thomas, you are really welcome to help us with pushing those features. Others as well. LieGrue, strub - Original Message - From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 13 November 2013, 23:51 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @Romain: I understand all your concerns - really! But from the view of CODI users, the current situation is quite disappointing because the most required CODI features are still not available since over a year IMO 1.0 should contain all important features. I would be happy if we could import Gerhards port of the CODI features for a 1.0 and enhance/reimplement the internal stuff later. Anyway, i think DS is currently already quite stable and a 1.0 is really required after this long time. But, as gerhard already stated, a better documentation and examples is really the minimum! I would also take the same version for each module. Its also easier to maintain for the users. 2013/11/13 Cody Lerum cody.le...@gmail.com +1 for a 1.0 when docs are in order. As far as versioning I prefer the same ver for each module. I do dislike potentially having to release the exact same code multiple times just under a different version but I don't know what the alternatives would be. If you have modules with different version numbers it tends to make the users pom very brittle. On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote: FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a table on the website what the maturity of each module is. On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote: Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress
Re: [DISCUSS] next release version? 0.6 or 1.0?
if there wouldn't be a blocker (for ds), i would have done/suggested it already. - -1 for a 1:1 import regards, gerhard 2013/11/14 Mark Struberg strub...@yahoo.de Thomas, you are really welcome to help us with pushing those features. Others as well. LieGrue, strub - Original Message - From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 13 November 2013, 23:51 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @Romain: I understand all your concerns - really! But from the view of CODI users, the current situation is quite disappointing because the most required CODI features are still not available since over a year IMO 1.0 should contain all important features. I would be happy if we could import Gerhards port of the CODI features for a 1.0 and enhance/reimplement the internal stuff later. Anyway, i think DS is currently already quite stable and a 1.0 is really required after this long time. But, as gerhard already stated, a better documentation and examples is really the minimum! I would also take the same version for each module. Its also easier to maintain for the users. 2013/11/13 Cody Lerum cody.le...@gmail.com +1 for a 1.0 when docs are in order. As far as versioning I prefer the same ver for each module. I do dislike potentially having to release the exact same code multiple times just under a different version but I don't know what the alternatives would be. If you have modules with different version numbers it tends to make the users pom very brittle. On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote: FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a table on the website what the maturity of each module is. On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote: Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re
Re: [DISCUSS] next release version? 0.6 or 1.0?
Mark, i know - we are all full of work. I could of course help to refactor the ViewAccessScoped stuff but i have no idea how the new API should look like or whats exactly not that good in the current implementation. I have not that expierence from the CODI development like you and Gerhard. Its not a angry critic! the current situation is only not that satifying for CODI users and DS feels really incomplete for JSF users. 2013/11/14 Gerhard Petracek gpetra...@apache.org if there wouldn't be a blocker (for ds), i would have done/suggested it already. - -1 for a 1:1 import regards, gerhard 2013/11/14 Mark Struberg strub...@yahoo.de Thomas, you are really welcome to help us with pushing those features. Others as well. LieGrue, strub - Original Message - From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Wednesday, 13 November 2013, 23:51 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @Romain: I understand all your concerns - really! But from the view of CODI users, the current situation is quite disappointing because the most required CODI features are still not available since over a year IMO 1.0 should contain all important features. I would be happy if we could import Gerhards port of the CODI features for a 1.0 and enhance/reimplement the internal stuff later. Anyway, i think DS is currently already quite stable and a 1.0 is really required after this long time. But, as gerhard already stated, a better documentation and examples is really the minimum! I would also take the same version for each module. Its also easier to maintain for the users. 2013/11/13 Cody Lerum cody.le...@gmail.com +1 for a 1.0 when docs are in order. As far as versioning I prefer the same ver for each module. I do dislike potentially having to release the exact same code multiple times just under a different version but I don't know what the alternatives would be. If you have modules with different version numbers it tends to make the users pom very brittle. On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote: FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a table on the website what the maturity of each module is. On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote: Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for a 1.0 when docs are in order. As far as versioning I prefer the same ver for each module. I do dislike potentially having to release the exact same code multiple times just under a different version but I don't know what the alternatives would be. If you have modules with different version numbers it tends to make the users pom very brittle. On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote: FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a table on the website what the maturity of each module is. On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote: Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for v1. If we don't go back (= we don't make unstable stable modules) it is enough IMO
Re: [DISCUSS] next release version? 0.6 or 1.0?
@mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Re: [DISCUSS] next release version? 0.6 or 1.0?
the minimum before v1: everybody documents the feature/s they added (/helped with) within the next weeks. (for sure the rest is very welcome to join and/or provide feedback.) if we don't handle it as a blocker for v1, it won't happen any time soon. the optimum before v1: docs + examples + agreed versioning strategy regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 12 November 2013, 16:18 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same
Re: [DISCUSS] next release version? 0.6 or 1.0?
-1 for 1.0 - till adding the most important features from CODI (e.g. ViewAccessScoped) 2013/11/12 Gerhard Petracek gerhard.petra...@gmail.com the minimum before v1: everybody documents the feature/s they added (/helped with) within the next weeks. (for sure the rest is very welcome to join and/or provide feedback.) if we don't handle it as a blocker for v1, it won't happen any time soon. the optimum before v1: docs + examples + agreed versioning strategy regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Tuesday, 12 November 2013, 16:18 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? @mark: i never said that we should do #2. regards, gerhard 2013/11/12 Mark Struberg strub...@yahoo.de Pete, Gerhard The Problem here is that there are only 2 ways to handle the situation: 1.) all modules share the same version but have different maturity grades 2.) each module has it's very own version. A 0.x reflects instability, 1.x reflects maturity. But you know what happened with exactly this approach in Seam3? The problem is that users do not know which version of ds-jsf-api works together with which version of ds-core-impl for example. It gets much more complicated with later modules. Thus I prefer 1.). LieGrue, strub From: Pete Muir pm...@redhat.com To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with docs, but the person I had in mind just left Red Hat :-(. Also +1 to going to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com wrote: if we move to v1 soon, we need an useful versioning strategy, better docs and examples + the api and spi need to be stable for some time (in the best case until v2+). regards, gerhard 2013/11/11 Mark Struberg strub...@yahoo.de how should that work? Please note that we will have some not perfectly finished modules very often. Basically whenever we add a new module... There is just no way to avoid this other than making those modules own releases. But this does not work out neither (as seen on a few other projects I don't like to name). LieGrue, strub From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org Sent: Monday, 11 November 2013, 20:54 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I
[DISCUSS] next release version? 0.6 or 1.0?
Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub
Re: [DISCUSS] next release version? 0.6 or 1.0?
Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub
Re: [DISCUSS] next release version? 0.6 or 1.0?
Well if code is released it should be stable or explicitely in alpha/beta..maybe we should do subreleases for unstables modules Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit : Oki folks, txs 4 the feedback, all! I'd say we should create the module-maturity-matrix.md first and then we might do the version bump. Maybe something like green/blue/orange/red for mature / ready but still needs a few features / ready but might change it's api still / work in progress LieGrue, strub - Original Message - From: Charles Moulliard ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, 11 November 2013, 18:25 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to move to 1.0. We have done the same thing with Apache Aries moving Blueprint from 0.5 to 1.0 release On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it in production with 0.x And the actual answer is: well, core, cdictrl, etc are stable since a long time, other modules are not yet 100% where we like them. The other fact is that we will never get all our modules 100% stable. Because new modules cannot be released with the same quality than established and well known and bugfixed modules. Thus I think we should rather introduce a kind of majurity-matrix for DeltaSpike. A simple list of modules and their majurity grade. By officially moving to 1.0 we would gain much more users. I personally do not care about numbers, but LOTS of users do! Wdyt? LieGrue, strub -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
