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.schai...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
