commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [SCXML] Next major version number required package rename needed?
Date Thu, 10 Oct 2013 23:52:37 GMT
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 <ate@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


Mime
View raw message