The dots aren't decimal separators and version numbers are not true numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal numbers, you couldn't have more than one dot.
0.9 to 1.0 is a major version jump. However, 0.X usually indicates pre-release quality (i.e., not ready for production yet). Paul On Thu, Oct 10, 2013 at 7:40 PM, Niall Pemberton <niall.pember...@gmail.com>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>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-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 > > > > > -- Cheers, Paul
