commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 11:36:46 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message