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
