commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
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:

[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 <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
View raw message