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