commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [SCXML] Next major version number required package rename needed?
Date Fri, 11 Oct 2013 08:51:22 GMT
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 <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-
>


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


Mime
View raw message