Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for pushing out 0.6 ASAP and 1.0 as soon as all the "must have" features are complete. 2014-02-17 10:10 GMT+01:00 Mark Struberg : > 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 : > >> 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 > wrote: > >> > >> That's reasonable enough. > >>> > >>> > >>>On 16. feb. 2014, at 23:02, Jason Porter > 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 > 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! > >>> > >>> > >>> > > > > > > > -- 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?
Hi Antoine, it's good to hear that more red hat committers are on its way :) On 17 Feb 2014, at 16:22, Antoine Sabot-Durand wrote: > Yes Ove, too few Red Hat committers. But they’re will be one more when CDI > 1.2 will be out and work for preparing CDI 2.0 will be on track. > > Antoine Sabot-Durand > ——— > Twitter : @antoine_sd > CDI co-spec lead & eco-system development > Agorava tech lead > > > Le 16 févr. 2014 à 22:38, Ove Ranheim a écrit : > >> 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 >> 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 : >>> +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 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 > 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 : >>> 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 wrote: >>> >>> That's reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter 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 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 >> 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 >>> : >>> +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?
Yes Ove, too few Red Hat committers. But they’re will be one more when CDI 1.2 will be out and work for preparing CDI 2.0 will be on track. Antoine Sabot-Durand ——— Twitter : @antoine_sd CDI co-spec lead & eco-system development Agorava tech lead Le 16 févr. 2014 à 22:38, Ove Ranheim a écrit : > 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 > 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 : >> >>> +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?
Mark, Dunno for the one week delay for 0.6 and 3 weeks delay for 1.0, but +1 to go with an intermediate step (ie. 0.6). JLouis 2014-02-17 13:14 GMT+01:00 Thomas Andraschko : > +1 Mark > > > > 2014-02-17 13:08 GMT+01:00 Ove Ranheim : > > > +1 for this :) > > > > > > 2014-02-17 10:10 GMT+01:00 Mark Struberg : > > > > > 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 : > > > >> 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 > > > > wrote: > > > >> > > > >> That's reasonable enough. > > > >>> > > > >>> > > > >>>On 16. feb. 2014, at 23:02, Jason Porter > > > 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 > > > 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! > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > -- Jean-Louis
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 Mark 2014-02-17 13:08 GMT+01:00 Ove Ranheim : > +1 for this :) > > > 2014-02-17 10:10 GMT+01:00 Mark Struberg : > > > 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 : > > >> 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 > > wrote: > > >> > > >> That's reasonable enough. > > >>> > > >>> > > >>>On 16. feb. 2014, at 23:02, Jason Porter > > 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 > > 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 : > 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 : > >> 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 > wrote: > >> > >> That's reasonable enough. > >>> > >>> > >>>On 16. feb. 2014, at 23:02, Jason Porter > 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 > 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 Documentation and examples are never complete but with that in mind one should not stop improving them "because they are never complete anyway" ;-) On Mon, Feb 17, 2014 at 11:10 AM, Mark Struberg 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 : > >> 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 > wrote: > >> > >> That's reasonable enough. > >>> > >>> > >>>On 16. feb. 2014, at 23:02, Jason Porter > 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 > 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! > >>> > >>> > >>> > > > > > > > -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 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 : >> 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 wrote: >> >> That's reasonable enough. >>> >>> >>>On 16. feb. 2014, at 23:02, Jason Porter 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 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 > 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 >> : >> >>> +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 : > 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 wrote: > > That's reasonable enough. >> >> >>On 16. feb. 2014, at 23:02, Jason Porter 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 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 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 > : > >> +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?
IMHO ViewAccessScoped is a showstopper for the JSF users. Many people used CODI just because of it! But to be honest, if i will do it, it takes propably 2-4 weeks. I have currently only time at weekend... and i'm note sure if i know all details of the implementation ;) 2014-02-17 9:57 GMT+01:00 Mark Struberg : > 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 > wrote: > > That's reasonable enough. > > > > > >On 16. feb. 2014, at 23:02, Jason Porter 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 > 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?
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 wrote: That’s reasonable enough. > > >On 16. feb. 2014, at 23:02, Jason Porter 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 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 >>> 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 : > +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?
That’s reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter 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 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 >> 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 : >>> +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 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 > 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 : >> >>> +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?
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 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 : > >> +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 : > +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 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 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 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 : > >> 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 wrote: >> >>> I'd be +1 for 1.0 >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>> On Sunday, 16 February 2014, 14:52, Nicklas Karlsson >> 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 >> 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. >>>>> >>
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 : > 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 wrote: > > > I'd be +1 for 1.0 > > > > LieGrue, > > strub > > > > > > > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > 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 > 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 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 > >
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 wrote: > I'd be +1 for 1.0 > > LieGrue, > strub > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > 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 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 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 >>>>> 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 >>>>> >>>>>> 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 >>>
Re: [DISCUSS] next release version? 0.6 or 1.0?
When do you like to release, Mark? I would like to finish ViewAccessScoped before 1.0 - and we should completely finish the documentation!!! So it will take some more weeks... 2014-02-16 16:43 GMT+01:00 Gerhard Petracek : > imo v0.6 is way overdue. > > @nik: > that's the issue - there are still several undocumented parts (also see > e.g. [1]) and there are only few examples. > > regards, > gerhard > > [1] http://s.apache.org/gf9 > > > > 2014-02-16 16:39 GMT+01:00 Mark Struberg : > > > I'd be +1 for 1.0 > > > > LieGrue, > > strub > > > > > > > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > > > 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 > 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 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 > > >> >> 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 > > >> >&g
Re: [DISCUSS] next release version? 0.6 or 1.0?
imo v0.6 is way overdue. @nik: that's the issue - there are still several undocumented parts (also see e.g. [1]) and there are only few examples. regards, gerhard [1] http://s.apache.org/gf9 2014-02-16 16:39 GMT+01:00 Mark Struberg : > I'd be +1 for 1.0 > > LieGrue, > strub > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > 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 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 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 > >> >> 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 > >> >> > >> >>> 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 > >> >>>
Re: [DISCUSS] next release version? 0.6 or 1.0?
I'd be +1 for 1.0 LieGrue, strub On Sunday, 16 February 2014, 14:52, Nicklas Karlsson 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 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 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 >> >> 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 >> >> >> >>> 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 >> >>>> 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 >> g
Re: [DISCUSS] next release version? 0.6 or 1.0?
(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 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 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 > >> 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 > >> > >>> 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 > >>>> 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 > >> > >>> 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+). > >>>>> > >>>>&g
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 : > 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 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 > >> 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 > >> > >>> 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 > >>>> 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 > >> > >>> 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 > >>>>> > >>>>>> > >>>>>> > >>>>>> 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). > >>>&g
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 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 >> 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 >> >>> 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 >>>> 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 >> >>> 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 >>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>>> To: Mark Struberg ; >> 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 b
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 wrote: > +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 > > > 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" 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 > > > > To: dev@deltaspike.apache.org > > > > Cc: Mark Struberg > > > > 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 > > > > wrote: > > > > > > > >> 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 > > > > > 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?
+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 > 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" 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 > > > To: dev@deltaspike.apache.org > > > Cc: Mark Struberg > > > 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 > > > wrote: > > > > > >> 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 > > > 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?
hi thomas, e.g.: the new window-api doesn't fit to the api/spi of codi (see WindowContext - same name, but different artifact) regards, gerhard 2013/11/14 Thomas Andraschko > 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 > > > 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 > > > > > Thomas, you are really welcome to help us with pushing those features. > > > Others as well. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > - Original Message - > > > > From: Thomas Andraschko > > > > 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 > > > > > > > >> +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 > 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 > > > > 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. > > > >> > > > > >
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 > 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 > > > Thomas, you are really welcome to help us with pushing those features. > > Others as well. > > > > LieGrue, > > strub > > > > > > > > > > - Original Message - > > > From: Thomas Andraschko > > > 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 > > > > > >> +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 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 > > > 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 > > >> > >> 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 > > >>
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 > Thomas, you are really welcome to help us with pushing those features. > Others as well. > > LieGrue, > strub > > > > > - Original Message - > > From: Thomas Andraschko > > 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 > > > >> +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 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 > > 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 > >> > >> 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 > >> > >>> > >> > >>> > >> > >>> > >> > >>> 20
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 wrote: > Thomas, you are really welcome to help us with pushing those features. > Others as well. > > LieGrue, > strub > > > > > - Original Message - > > From: Thomas Andraschko > > 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 > > > >> +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 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 > > 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 > >> > >> 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+). &
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 > 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 > >> +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 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 > 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 >> > >> 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 >> > >>> >> > >>>> >> > >>>> >> > >>>> 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&#
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 > +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 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 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 > > >> 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 > > >>> > > >>>> > > >>>> > > >>>> 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 > > >>>>> To: Mark Struberg ; 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" a > écrit : > > >>
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 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 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 > >> 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 > 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 > >>> > >>>> > >>>> > >>>> 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 > >>>>> To: Mark Struberg ; 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" 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 > >>>>>>> To: dev@deltaspike.apache.org > >>>>>>> Cc: Mark Struberg > >>>>>>> Sent: Monday, 11 November 2013, 18:25 > >>>>>>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >>>>>>> > >>>>&
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 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 >> 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 >> 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 >>> >>>> >>>> >>>> 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 >>>>> To: Mark Struberg ; 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" 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 >>>>>>> To: dev@deltaspike.apache.org >>>>>>> Cc: Mark Struberg >>>>>>> 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 >>>>>>> wrote: >>>>>>> >>>>>>>> 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. >>>>>>>>
Re: [DISCUSS] next release version? 0.6 or 1.0?
@Thomas: does 1 mean "we can replace codi" or "you can use me". I think the initial statement is right: if we dont do a 1 (foe Xmas?) We'll not get that much users. The version mainly constraint us to be stable on package and existing signatures (for code, doc etc are needed too), not really more IMO. Le 13 nov. 2013 04:00, "Thomas Andraschko" a écrit : > -1 for 1.0 - till adding the most important features from CODI (e.g. > ViewAccessScoped) > > > 2013/11/12 Gerhard Petracek > > > 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 > > > > > 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 > > > > 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 > > > > > > > >> 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 > > > >> >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 > > > > > > > >> 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 > > > >> >> > > > >> >>> > > > >> >>> > > > >> >>> how should that work? > > > >> >>> > > &
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 > 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 > > > 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 > > > 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 > > > > > >> 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 > > >> >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 > > > > > >> 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 > > >> >> > > >> >>> > > >> >>> > > >> >>> 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 > > >> >>>> To: Mark Struberg ; > > > dev@deltaspik
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 > 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 > > 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 > > > >> 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 > >> >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 > > > >> 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 > >> >> > >> >>> > >> >>> > >> >>> 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 > >> >>>> To: Mark Struberg ; > > 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" > > a écrit : > >> >>>> > >> >>>> Oki folks, txs 4 the feedback, all! > >> >>>>> > >> >>>>> >
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 > 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 > >> 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 >> >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 > >> 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 >> >> >> >>> >> >>> >> >>> 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 >> >>>> To: Mark Struberg ; > 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" > 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 >> >>>>>> To: dev@deltaspike.apache.org >> >>>>>> Cc: Mark Struberg >> >>>>>> Sent: Monday, 11 November 2013, 18
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 > 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 > >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 > 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 > >> > >>> > >>> > >>> 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 > >>>> To: Mark Struberg ; 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" 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 > >>>>>> To: dev@deltaspike.apache.org > >>>>>> Cc: Mark Struberg > >>>>>> 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 > >>>>>> wrote: > >>>>>> > >>>>>>> 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 > > >>>>>> 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?
I agree with Mark. +1 for 1 best regards, Nathan Dennis | Software Developer 732 Greenwood Street | Albemarle, NC | 28001 Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829 www.monarchnc.org | nathan.den...@monarchnc.org -Original Message- From: Mark Struberg [mailto:strub...@yahoo.de] Sent: Tuesday, November 12, 2013 9:34 AM To: dev@deltaspike.apache.org Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? 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 >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 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 >> >>> >>> >>> 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 >>>> To: Mark Struberg ; 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" 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 >>>>>> To: dev@deltaspike.apache.org >>>>>> Cc: Mark Struberg >>>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>> wrote: >>>>&g
Re: [DISCUSS] next release version? 0.6 or 1.0?
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 >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 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 >> >>> >>> >>> 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 >>>> To: Mark Struberg ; 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" 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 >>>>>> To: dev@deltaspike.apache.org >>>>>> Cc: Mark Struberg >>>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>> 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?
I think if we get a 1.0 out there, then focus on the docs it should be fine. On Tue, Nov 12, 2013 at 8:35 AM, Pete Muir wrote: > +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 > 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 > > > >> > >> > >> 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 > >>> To: Mark Struberg ; 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" 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 > >>>>> To: dev@deltaspike.apache.org > >>>>> Cc: Mark Struberg > >>>>> 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 > >>>>> wrote: > >>>>> > >>>>>> 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 > >>>>> 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 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 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 > >> >> >> 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 >>> To: Mark Struberg ; 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" 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 >>>>> To: dev@deltaspike.apache.org >>>>> Cc: Mark Struberg >>>>> 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 >>>>> wrote: >>>>> >>>>>> 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 >>>>> 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?
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 > > > 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 > >To: Mark Struberg ; 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" 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 > >>> To: dev@deltaspike.apache.org > >>> Cc: Mark Struberg > >>> 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 > >>> wrote: > >>> > >>>> 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 > >>> 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?
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 >To: Mark Struberg ; 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" 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 >>> To: dev@deltaspike.apache.org >>> Cc: Mark Struberg >>> 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 >>> wrote: >>> >>>> 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 >>> 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?
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" 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 > > To: dev@deltaspike.apache.org > > Cc: Mark Struberg > > 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 > > wrote: > > > >> 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 > > 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?
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 > To: dev@deltaspike.apache.org > Cc: Mark Struberg > 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 > wrote: > >> 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 > 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 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 wrote: > 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 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?
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 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?
I was okay moving to 1.0 with 0.5. +1 for moving to 1.0 now. On Mon, Nov 11, 2013 at 10:08 AM, Mark Struberg 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 > -- Jason Porter http://en.gravatar.com/lightguardjp
