You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Ate Douma <at...@douma.nu> on 2013/10/11 01:06:00 UTC

[SCXML] Next major version number required package rename needed?

On 10/10/2013 09:39 PM, Rahul Akolkar wrote:
> On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <at...@douma.nu> wrote:
<snip/>

>>
>> Case in point: SCXML
>> If we are allowed to start working on this component shortly, we intend to,
>> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
>> release out, while we will need to move to newer JDK and incompatible API
>> changes anyway. At the same time, getting a final/stabalized 1.0 release out
>> most certainly will take several iterations.
> <snip/>
>
> Release version comparisons being what the are, we could go to v0.10,
> as in below (greater than sign implies more recent release version):
>
> 0.11 > 0.10 > 0.9

For the intended promotion of the SCXML J6 branch to trunk, I don't think that 
would align with the Commons versioning scheme.

The SCXML J6 branch (which currently already uses version 1.0-SNAPSHOT) imposes 
API breaking changes from the 0.9 release, as well as targets a newer JDK (1.6+).
AFAIK this will require a major version bump, hence should target version 1.0.

I thus intend to roll out a first intermediate release of this new trunk as 
version 1.0-alpha-1 (as discussed earlier today in a separate thread).

What however is still unclear to me is if this also requires a package rename, 
e.g. move from org.apache.commons.scxml.* -> org.apache.commons.scxml1.* ?

I got the impression from other discussions as well as from looking at other 
components recent major versions, that this now also is a rule or policy within 
Commons. But I can't find any specific writing about such 'policy'.
At least the online Versioning document doesn't say anything about it, or I must 
be blindly overlooking it.

So my question is: is such package rename now a required rule, or more of a 
convention?

And if this was established as a formal requirement, can someone point me out 
the documentation (or maybe VOTE thread) for it?

Thanks, Ate

>
> Not very different than, say the following, which may appear more
> intuitive for release versions (agree 0.x line is trickier):
>
> 2.11 > 2.10 > 2.9
>
> Overall, I think it's OK to go the 0.10 route, if you want to save a
> 1.0 major release for later at a point it's really needed.
>
> In hindsight, the first Commons SCXML release could've been 0.1
> (rather than 0.5) to give more room for 4 more releases before getting
> to this point :-)
>
> -Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [SCXML] Next major version number required package rename needed?

Posted by Benedikt Ritter <br...@apache.org>.

2013/10/11 Ate Douma <at...@douma.nu>

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

+1, let's do a 2.0


>
> Thank you all for the feedback,


Thanks you for pushing this forward!


>
> 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
>>> <james@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 <at...@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>
>>>
>>>> <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-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>  ------------------------------****----------------------------**
>>>> --**---------
>>>>
>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-
>>>>>
>>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [SCXML] Next major version number required package rename needed?

Posted by Ate Douma <at...@douma.nu>.

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
>> <james@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 <at...@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [SCXML] Next major version number required package rename needed?

Posted by James Carman <ja...@carmanconsulting.com>.

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
> <james@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 <at...@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-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-

Re: [SCXML] Next major version number required package rename needed?

Posted by Matt Benson <gu...@gmail.com>.

I would also treat 0.9 as a "real release" and act accordingly wrt API
changes; the current release is far too old to do otherwise IMHO.

Matt
On Oct 10, 2013 7:41 PM, "Niall Pemberton" <ni...@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 <at...@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-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [SCXML] Next major version number required package rename needed?

Posted by Paul Benedict <pb...@apache.org>.

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
<ni...@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 <at...@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-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>



-- 
Cheers,
Paul

Re: [SCXML] Next major version number required package rename needed?

Posted by Niall Pemberton <ni...@gmail.com>.

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 <at...@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ------------------------------**------------------------------**---------
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [SCXML] Next major version number required package rename needed?

Posted by James Carman <ja...@carmanconsulting.com>.

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 <at...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**---------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [SCXML] Next major version number required package rename needed?

Posted by Ate Douma <at...@douma.nu>.

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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org