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.
Thank you all for the feedback,
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>
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-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
