Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma <at...@douma.nu>]

Sigh, typical mistake of forgetting to provide the link referenced further below:

[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases

On 10/10/2013 01:26 PM, Ate Douma wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I proposed
> earlier to support releasing intermediate versions of a not-yet-stabalized
> component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to remain
> stable, I don't agree this is, or should be, the common case. Or at least not an
> argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving *faster*
> by allowing *experimental* end-users to provide feedback, and more flexibility
> and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a project
> clearly is not ready to stabalize, really puts way too much hurdles up for both
> the developers *and* such experimental end-users, as they would HAVE to change
> all of their code to be able to provide AND leaverage such new 0.x or Milestone
> version.
>
> 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.
> I don't want to have to wait doing an intermediate release, nor rapidly having
> to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are
> acceptable for this purpose.
Of course I inteded to say 'just because Milestone releases are NOT acceptable 
for this purpose'.

> Where would Milestone releases [1] be useful for
> otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party libraries)
> would start depending directly on such Milestone releases, potentially
> introducing unexpected instabilities for end-users. And maybe it is worthwhile
> to make such usages, at least for Commons, prohibited. That would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be a
> real issue. Those end-users making use of these experimental components are, or
> should be very well aware, of the added responsibility they take depending on a
> not-yet-stabilized version, as clearly is also indicated by the version, as well
> as SHOULD be prominently documented in the release notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>> I like the idea of releasing 0.x versions. A good example is [csv]. I would
>> have no problem with releasing the current trunk as 0.9. At the moment [csv]
>> is just another component we don't releaese because we want to come up with a
>> perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <Jo...@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>> Every now and then I keep getting requests via private mail asking to
>>>>> release javaflow as it seems to be working for people. Yet I know there
>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>
>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>> release already ages ago but knowing I won't have time to work on it
>>>>> anymore I keep pushing this out at commons.
>>>>
>>>> Wouldn't this be a case to allow and use intermediate milestone releases?
>>>>
>>>> Using a 1.0-Mxx version would make still clear to the users things haven't
>>>> settled yet (API wise), so should not limit or restrict making API changes
>>>> before a final 1.0 release, but would help both the community and the
>>>> project moving. More likely to incite further involvement and
>>>> contributions, etc.
>>>>
>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>>> at all.
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to be
>>> cumbersome in some cases. Typically you may also increase Java level in the
>>> meantime and therefore eventually even have a benefit of new possibilities.
>>>
>>>> "Release early and often" really is what keeps open source projects moving
>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>> fixed.
>>>>
>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>> should NOT block getting to a 1.0 release easily.
>>>> And I don't think they do. Isn't this where Milestone releases are meant
>>>> for?
>>>
>>> I am not a big fan of milestones unless we really have a forced schedule for
>>> the final release. If we get into the situation that the milestone is the
>>> latest release for months, we get into jar hell again, because that
>>> milestone is then *used* like any proper release. You cannot prevent this.
>>>
>>> There is a reason why I have to use for a (private) Maven plugin an artifact
>>> like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
>>> That's a result of such a "milestone" and I really like to avoid this
>>> situation for Apache Commons.
>>>
>>>>> Release and put into dormant?
>>>>> It's a strange situation.
>>>
>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already based
>>> on old technology.
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman <ja...@carmanconsulting.com>]

Rookie ;).  You had me at "faster"! :)

On Thursday, October 10, 2013, Ate Douma wrote:

> Sigh, typical mistake of forgetting to provide the link referenced further
> below:
>
> [1] http://commons.apache.org/**releases/versioning.html#**
> Milestone_Releases<http://commons.apache.org/releases/versioning.html#Milestone_Releases>
>
> On 10/10/2013 01:26 PM, Ate Douma wrote:
>
>> I've move this into a separate [DISCUSS] thread as I think it needs
>> separate
>> discussion.
>>
>> Jörg gave some objections below about using Milestone releases, as I
>> proposed
>> earlier to support releasing intermediate versions of a not-yet-stabalized
>> component.
>>
>> While I understand his problems with unstable versions potentially getting
>> 'stuck' for long time, where end-users *might* start expecting them to
>> remain
>> stable, I don't agree this is, or should be, the common case. Or at least
>> not an
>> argument to hold against using such 0.x or -Milestone releases.
>>
>> Instead, the whole point is to get project/component development moving
>> *faster*
>> by allowing *experimental* end-users to provide feedback, and more
>> flexibility
>> and convenience for the developers of such project/component.
>>
>> The idea to have to 'switch' to a next major version for any incompatibile
>> change, as Jörg proposes, requiring package changes, whatnot, while a
>> project
>> clearly is not ready to stabalize, really puts way too much hurdles up
>> for both
>> the developers *and* such experimental end-users, as they would HAVE to
>> change
>> all of their code to be able to provide AND leaverage such new 0.x or
>> Milestone
>> version.
>>
>> 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.
>> I don't want to have to wait doing an intermediate release, nor rapidly
>> having
>> to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases
>> are
>> acceptable for this purpose.
>>
> Of course I inteded to say 'just because Milestone releases are NOT
> acceptable for this purpose'.
>
>  Where would Milestone releases [1] be useful for
>> otherwise, anyway?
>>
>> I think a real problem might arise IF other components (or 3rd party
>> libraries)
>> would start depending directly on such Milestone releases, potentially
>> introducing unexpected instabilities for end-users. And maybe it is
>> worthwhile
>> to make such usages, at least for Commons, prohibited. That would make
>> sense to me.
>>
>> But for components like SCXML, javaflow, or csv, this I don't think would
>> be a
>> real issue. Those end-users making use of these experimental components
>> are, or
>> should be very well aware, of the added responsibility they take
>> depending on a
>> not-yet-stabilized version, as clearly is also indicated by the version,
>> as well
>> as SHOULD be prominently documented in the release notes, readme, etc.
>>
>> Thoughts?
>>
>> Ate
>>
>> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>>> would
>>> have no problem with releasing the current trunk as 0.9. At the moment
>>> [csv]
>>> is just another component we don't releaese because we want to come up
>>> with a
>>> perfect API (and I take responsibility for that :-)
>>>
>>> Benedikt
>>>
>>> Send from my mobile device
>>>
>>>  Am 10.10.2013 um 12:15 schrieb Jörg Schaible <
>>>> Joerg.Schaible@scalaris.com>:
>>>>
>>>> Hi,
>>>>
>>>> Ate Douma wrote:
>>>>
>>>>  On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>>> Every now and then I keep getting requests via private mail asking to
>>>>>> release javaflow as it seems to be working for people. Yet I know
>>>>>> there
>>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>>
>>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>>> release already ages ago but knowing I won't have time to work on it
>>>>>> anymore I keep pushing this out at commons.
>>>>>>
>>>>>
>>>>> Wouldn't this be a case to allow and use intermediate milestone
>>>>> releases?
>>>>>
>>>>> Using a 1.0-Mxx version would make still clear to the users things
>>>>> haven't
>>>>> settled yet (API wise), so should not limit or restrict making API
>>>>> changes
>>>>> before a final 1.0 release, but would help both the community and the
>>>>> project moving. More likely to incite further involvement and
>>>>> contributions, etc.
>>>>>
>>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>>> should be settled and 'frozen' (API wise) first doesn't make sense to
>>>>> me
>>>>> at all.
>>>>>
>>>>
>>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>>> be
>>>> cumbersome in some cases. Typically you may also increase Java level in
>>>> the
>>>> meantime and therefore eventually even have a benefit of new
>>>> possibilities.
>>>>
>>>>  "Release early and often" really is what keeps open source projects
>>>>> moving
>>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>>> fixed.
>>>>>
>>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>>> should NOT block getting to a 1.0 release easily.
>>>>> And I don't think they do. Isn't this where Milestone releases are
>>>>> meant
>>>>> for?
>>>>>
>>>>
>>>> I am not a big fan of milestones unless we really have a forced
>>>> schedule for
>>>> the final release. If we get into the situation that the milestone is
>>>> the
>>>> latest release for months, we get into jar hell again, because that
>>>> milestone is then *used* like any proper release. You cannot prevent
>>>> this.
>>>>
>>>> There is a reason why I have to use for a (private) Maven plugin an
>>>> artifact
>>>> like org.codehaus.plexus:plexus-**container-default:jar:1.0-**
>>>> alpha-9-stable-1.
>>>> That's a result of such a "milestone" and I really like to avoid this
>>>> situation for Apache Commons.
>>>>
>>>>  Release and put into dormant?
>>>>>> It's a strange situation.
>>>>>>
>>>>>
>>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already
>>>> based
>>>> on old technology.
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> 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
>
>