Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <5257BC0A.8010602@douma.nu>
References: 
 <CAB917RLfxx3peR30HsM4dWQ04EXrzZ_KoPGZAiccd6oFjHd5Sg@mail.gmail.com>
	<CAPCjjnFvhLbyZvNoejaXSjUQzVay3BxHFn17XD+xArHOzZZMMQ@mail.gmail.com>
	<l34elo$20p$1@ger.gmane.org>
	<CACZkXPw-VtbDJD9Dzs5vo7_vbfSdeFsCpNZ4SHQ856tqj_yuyQ@mail.gmail.com>
	<CAEQx=xkK17thM2-4Z+6vkB9b8FKmBfezTf5dGmU8mHndm8ohuA@mail.gmail.com>
	<5256735D.8090507@douma.nu>
	<l35une$1d7$1@ger.gmane.org>
	<635E8419-B316-4E95-8390-45B9065EBC82@gmail.com>
	<52568ECB.6040608@douma.nu>
	<CAN39H2SoN_XqZ4n-71QDkVqzRwvZ2ooHxwgZeJqWZa1GS3Z1sQ@mail.gmail.com>
	<525732D8.2000500@douma.nu>
	<52573550.7050604@apache.org>
	<52573867.7080303@douma.nu>
	<CALznzY5-zhTfQPEtF0f5=ZuH2ew0yGE-gKQ6W6SSEQ=SUZ0bMg@mail.gmail.com>
	<52573D0E.2000509@douma.nu>
	<CALznzY7ngcgqr=meePskK2cUpeqJzqHMa4TwBKZO+ynjQjPvHQ@mail.gmail.com>
	<CAPmHmDSzxWtMtU1p+00q=LMZw_kgor=oEkir6hkQXqGW9FfFKA@mail.gmail.com>
	<CALznzY4L5-a_hAUPoc673nGOL2kXBi5--qwpSHw=_L4VA0Ewwg@mail.gmail.com>
	<5257BC0A.8010602@douma.nu>
Date: Fri, 11 Oct 2013 11:18:23 +0200
Message-ID: 
 <CAB917RJHXk=dCH3rdPHmStRc-8DpzPTc6NRF1cb0f_sFcJdpow@mail.gmail.com>
Subject: Re: [SCXML] Next major version number required package rename needed?
From: Benedikt Ritter <britter@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5d97cbab444704e87399ad

--047d7b5d97cbab444704e87399ad
Content-Type: text/plain; charset=ISO-8859-1

2013/10/11 Ate Douma <ate@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 <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>
>>>
>>>> <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<dev-unsubscribe@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>  ------------------------------****----------------------------**
>>>> --**---------
>>>>
>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-
>>>>>
>>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@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

--047d7b5d97cbab444704e87399ad--