commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]
Date Thu, 10 Oct 2013 19:39:19 GMT
On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <ate@douma.nu> 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.
<snip/>

Release version comparisons being what the are, we could go to v0.10,
as in below (greater than sign implies more recent release version):

0.11 > 0.10 > 0.9

Not very different than, say the following, which may appear more
intuitive for release versions (agree 0.x line is trickier):

2.11 > 2.10 > 2.9

Overall, I think it's OK to go the 0.10 route, if you want to save a
1.0 major release for later at a point it's really needed.

In hindsight, the first Commons SCXML release could've been 0.1
(rather than 0.5) to give more room for 4 more releases before getting
to this point :-)

-Rahul



> 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. 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


Mime
View raw message