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