yea, but what are the alternatives? If you have a better idea, then tell us :)
The problem is that it's not only about the JSF module but about all other modules as well. LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <gerhard.petra...@gmail.com> > To: dev@deltaspike.apache.org > Cc: > Sent: Tuesday, 12 November 2013, 16:18 > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > @mark: > i never said that we should do #2. > > regards, > gerhard > > > > > 2013/11/12 Mark Struberg <strub...@yahoo.de> > >> Pete, Gerhard >> >> The Problem here is that there are only 2 ways to handle the situation: >> >> 1.) all modules share the same version but have different maturity grades >> >> 2.) each module has it's very own version. A 0.x reflects instability, > 1.x >> reflects maturity. But you know what happened with exactly this approach in >> Seam3? The problem is that users do not know which version of ds-jsf-api >> works together with which version of ds-core-impl for example. It gets much >> more complicated with later modules. >> >> Thus I prefer 1.). >> >> LieGrue, >> strub >> >> >> >> >> >________________________________ >> > From: Pete Muir <pm...@redhat.com> >> >To: dev@deltaspike.apache.org >> >Sent: Tuesday, 12 November 2013, 14:35 >> >Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >> > >> > >> >+1 to Gerhard’s point (I am looking to try to find someone to help with >> docs, but the person I had in mind just left Red Hat :-(. Also +1 to going >> to 1.0 soon (i.e. making docs and stability a priority!). >> > >> > >> >On 11 Nov 2013, at 23:09, Gerhard Petracek > <gerhard.petra...@gmail.com> >> wrote: >> > >> >> if we move to v1 soon, we need an useful versioning strategy, > better >> docs >> >> and examples + the api and spi need to be stable for some time (in > the >> best >> >> case until v2+). >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> 2013/11/11 Mark Struberg <strub...@yahoo.de> >> >> >> >>> >> >>> >> >>> how should that work? >> >>> >> >>> Please note that we will have some not perfectly finished > modules very >> >>> often. Basically whenever we add a new module... >> >>> There is just no way to avoid this other than making those > modules own >> >>> releases. But this does not work out neither (as seen on a few > other >> >>> projects I don't like to name). >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> >> >>> >> >>>> ________________________________ >> >>>> From: Romain Manni-Bucau <rmannibu...@gmail.com> >> >>>> To: Mark Struberg <strub...@yahoo.de>; > dev@deltaspike.apache.org >> >>>> Sent: Monday, 11 November 2013, 20:54 >> >>>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >> >>>> >> >>>> >> >>>> >> >>>> Well if code is released it should be stable or > explicitely in >> >>> alpha/beta..maybe we should do subreleases for unstables > modules >> >>>> Le 11 nov. 2013 18:43, "Mark Struberg" > <strub...@yahoo.de> a écrit : >> >>>> >> >>>> Oki folks, txs 4 the feedback, all! >> >>>>> >> >>>>> >> >>>>> I'd say we should create the > module-maturity-matrix.md first and >> then >> >>> we might do the version bump. >> >>>>> Maybe something like green/blue/orange/red for mature > / ready but >> still >> >>> needs a few features / ready but might change it's api > still / work in >> >>> progress >> >>>>> >> >>>>> >> >>>>> LieGrue, >> >>>>> strub >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> ----- Original Message ----- >> >>>>>> From: Charles Moulliard <ch0...@gmail.com> >> >>>>>> To: dev@deltaspike.apache.org >> >>>>>> Cc: Mark Struberg <strub...@yahoo.de> >> >>>>>> Sent: Monday, 11 November 2013, 18:25 >> >>>>>> Subject: Re: [DISCUSS] next release version? 0.6 > or 1.0? >> >>>>>> >> >>>>>> +1 to move to 1.0. We have done the same thing > with Apache Aries >> moving >> >>>>>> Blueprint from 0.5 to 1.0 release >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament >> >>>>>> <john.d.am...@gmail.com>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 <strub...@yahoo.de >> > >> >>>>>> wrote: >> >>>>>>> >> >>>>>>>> Hi! >> >>>>>>>> >> >>>>>>>> In the last 2 months I did a few > conference talks and smaller >> >>>>>>>> presentations (OpenBlend, W-JAX, ..) and > always got the same >> >>>>>> questions: >> >>>>>>>> "it's only a 0.x version, so is > it already stable? I >> >>>>>> don't like to use it >> >>>>>>>> in production with 0.x" >> >>>>>>>> >> >>>>>>>> And the actual answer is: "well, > core, cdictrl, etc are stable >> >>>>>> since a >> >>>>>>>> long time, other modules are not yet 100% > where we like them". >> >>>>>>>> >> >>>>>>>> The other fact is that we will never get > all our modules 100% >> >>> stable. >> >>>>>>>> Because new modules cannot be released > with the same quality than >> >>>>>>>> established and well known and bugfixed > modules. >> >>>>>>>> >> >>>>>>>> Thus I think we should rather introduce a > kind of majurity-matrix >> >>> for >> >>>>>>>> DeltaSpike. >> >>>>>>>> A simple list of modules and their > majurity grade. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> By officially moving to 1.0 we would gain > much more users. >> >>>>>>>> I personally do not care about numbers, > but LOTS of users do! >> >>>>>>>> >> >>>>>>>> Wdyt? >> >>>>>>>> >> >>>>>>>> LieGrue, >> >>>>>>>> strub >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Charles Moulliard >> >>>>>> Apache Committer / Architect @RedHat >> >>>>>> Twitter : @cmoulliard | Blog : > http://cmoulliard.github.io >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> > >> > >> > >> >