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
>>  >>>>>>
>>  >>>>>
>>  >>>>
>>  >>>>
>>  >>>
>>  >
>>  >
>>  >
>> 
>

Reply via email to