It wouldn't look so funky that way. I'm cool with that. 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> > > >>>> > > >>>> Emmanuel Bourg > > >>>> > > >>>> > > >>>> > > >>>> > > ------------------------------**------------------------------**--------- > > >>>> > > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>>> > > >>>> > > >>> > > >>> > > ------------------------------**------------------------------**--------- > > >>> > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>> > > >>> > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-
