I think "milestone" releases works if you have a clear development plan and schedule. I've never seen it be the case in Commons. Calling "releases" to Maven and dist, Alphas and Betas make more sense for us IMO.
Gary On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <a...@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. > 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.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 > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
