commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 11:32:26 GMT
Sigh, typical mistake of forgetting to provide the link referenced further below:


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 <>:
>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message