2013/10/11 Ate Douma <a...@douma.nu> > On 10/11/2013 02:54 AM, James Carman wrote: > >> It wouldn't look so funky that way. I'm cool with that. >> > > I'm leaning to this solution as well, going for scxml2 with version > 2.0(-xx). > > While this would 'skip' the 1.0 range, I think not only doesn't it look so > funky (scxml1) but also better indicate align with the current versioning > rules > which state that a first version should start with 1.0 to begin with. > SCXML clearly was started long before this became practice, hence its > current 0.x range. > But as we're about to 'restart' the component, using version 2.0 probably > is a beter indication of this 'second major version' for SCXML. > > If nobody further objects to this, I'll assume lazy consensus on this. >
+1, let's do a 2.0 > > Thank you all for the feedback, Thanks you for pushing this forward! > > Ate > > > >> On Thursday, October 10, 2013, Niall Pemberton wrote: >> >> I would bump to version 2.0 because I dont think its clear that going >>> from >>> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we >>> haven't quite completed everything we want to for 1.0" >>> >>> Niall >>> >>> >>> On Fri, Oct 11, 2013 at 12:52 AM, James Carman >>> <ja...@carmanconsulting.com <javascript:;>>wrote: >>> >>> Now, this case is a bit weird, since we have released code in a < 1.0 >>>> version number. So, the artifact/package will have to be scxml1, >>>> which looks funky IMHO. I guess that follows the pattern, though. >>>> >>>> On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <a...@douma.nu> wrote: >>>> >>>>> On 10/11/2013 01:41 AM, James Carman wrote: >>>>> >>>>>> >>>>>> If you are breaking backward compatibility then you need to do the >>>>>> >>>>> renames >>>> >>>>> (package, and artifactId). >>>>>> >>>>> >>>>> >>>>> That was my impression already. >>>>> And I have no real issue with doing so. >>>>> >>>>> But again, when has this been decided and has it ever been formalized >>>>> (written down) somewhere? >>>>> >>>>> >>>>> >>>>>> I don't know if we ever landed on a "rule" about the new JDK level >>>>>> scenario, though. >>>>>> >>>>> >>>>> Okay, maybe that was just an incorrect assumption. >>>>> >>>>> And it doesn't really matter as there will be breaking API changes >>>>> >>>> needed >>> >>>> for the next version of SCXML, so we'll have to bump the major version >>>>> anyway. >>>>> >>>>> >>>>>> On Thursday, October 10, 2013, Ate Douma wrote: >>>>>> >>>>>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: >>>>>>> >>>>>>> Commons SCXML has only one reverse dependency in Maven Central, >>>>>>>> flexistate, so I wouldn't bother with the binary compatibility and >>>>>>>> >>>>>>> just >>>> >>>>> keep the package as is. >>>>>>>> >>>>>>>> >>>>>>> Hmm. That might be the only reverse dependency of artifacts also >>>>>>> >>>>>> deployed >>>> >>>>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of >>>>>>> projects which might be impacted still. >>>>>>> >>>>>>> I would expect stronger arguments to decide yes/no if a package >>>>>>> >>>>>> rename >>> >>>> is >>>> >>>>> required or not. This would seem a bit (too) arbitrary to me. >>>>>>> >>>>>>> Mind you, I'd prefer not having to do a package rename, but I got the >>>>>>> impression there are more explicit 'rules' when to do so. >>>>>>> >>>>>>> So I'd still would like to hear more explicitly if such a rule is >>>>>>> defined, >>>>>>> and if so how it is worded and where. But of course if there is none, >>>>>>> fine >>>>>>> by me :) >>>>>>> >>>>>>> Thanks, Ate >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> http://mvnrepository.com/****artifact/commons-scxml/**** >>> commons-scxml/0.9<http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9> >>> >>>> <http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9> >>>> > >>>> >>>>> >>>>>>>> Emmanuel Bourg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------****----------------------------** >>>> --**--------- >>>> >>>>> >>>>>>>> To unsubscribe, e-mail: >>>>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ------------------------------****----------------------------** >>>> --**--------- >>>> >>>>> >>>>>>> To unsubscribe, e-mail: >>>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>>> For additional commands, e- >>>>> >>>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
