Gentlemen, big +1 from me too to speed up and stop the slavery of the 100 mad "fix me" rules. I will gladly vote +1 to releases which pass the unit tests but do not fulfill the maven reports (as long as I can't see really nasty bugs).
Cheers, Christian On Fri, Dec 2, 2011 at 9:45 PM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hi all guys, > I would like to confirm Henri Yandell's concern about the cutting > releases :( I honestly think we should speak less and practice more > the "releas early and often" karma because the sad reality is... we've > been not good on it :( > My Maven community experience let me totally astonished, we have > released the fluido-skin in ~160 commits and 1 RC, something that > would not be possible here. Of course we have issues there, but the > pragmatism and the agility are totally surprising, that's why they > have so many components/plugins/shared modules etc etc > OTOH here at commons we have commons-collections, or > commons-catastrophe like someone called in his blog: I recently > proposed a short-therm roadmap, the big mountain that appeared in > front of me simple made me feel to went away - it would have required > a year of work - in the meantime Google-Guava continues publishing > releases and we've lost users that migrated to more maintained > FWs.We've had the Generics enabled in collections for a long time - > even before that I joined as Sandbox contributor - but we've never > released because of, as Christian already explained, endless > discussions that induce people to give up. > I think we suffer the "fix X before release" and "follow the roadmap" > syndrome and we should add a little more of dynamism to improve. > oh, and btw: big +1 to Gary and James :) > > Just my 0.00002 cents, yours,Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Fri, Dec 2, 2011 at 9:08 PM, James Carman <ja...@carmanconsulting.com> > wrote: >> Also remember that releases can't be vetoed. Majority wins and must have 3 >> +1s. You'll have mine on a 3.x release! >> On Dec 2, 2011 2:40 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote: >> >>> On Fri, Dec 2, 2011 at 1:19 PM, sebb <seb...@gmail.com> wrote: >>> >>> > On 2 December 2011 17:52, Gary Gregory <garydgreg...@gmail.com> wrote: >>> > > +1. to release early, release often. >>> > >>> > But I hope we don't want to break user applications. >>> > >>> > > Go for v3, seems simplest. >>> > >>> > Simpler for whom? >>> > >>> >>> Simpler for people to use the latest version with new features. Users have >>> to make a conscious decision to upgrade to a new release, there is no >>> coercion. A new release, in 2.x or 3.x carries different migration costs. >>> If the new features of a 3.x matter to me, I accept the costs. If the >>> releasing a new feature is incompatible in 2.x, I have to deal getting it >>> in a 3.x with package name changes (and any other breakage.) >>> >>> Gary >>> >>> >>> > >>> > We could always release major versions with package and Maven id >>> > changes, and then compatibility issues would be irrelevant. >>> > >>> > However, would most end users want that? >>> > (JDBC versions, anyone?) >>> > >>> > Assuming that there are many more users of the code than there are >>> > developers, then I think the developers owe it to the users not to >>> > break things unnecessarily. >>> > Particularly for projects such as Commons, which are generally only a >>> > small part of a larger application. >>> > Projects like Tomcat or JMeter which are largely self-contained can >>> > afford to make many more internal changes, but they still need to >>> > ensure upwards compatibility as far as possible. >>> > >>> > > If someone really wants fixes in 2.x, then you release from the branch. >>> > >>> > The reason I started on this was to see if we could tweak the code >>> > sufficiently to avoid having to do a major version release. >>> > I think we are nearly there. >>> > >>> > So yes, more work for the developers, but a lot less hassle for most end >>> > users. >>> > >>> > > Gary >>> > > >>> > > On Fri, Dec 2, 2011 at 12:27 PM, henrib <hen...@apache.org> wrote: >>> > > >>> > >> I've done the same thing and been pushing JEXL snapshots for sometime >>> to >>> > >> avoid the unpleasant moment, so unpleasant that I've procrastinated >>> > enough >>> > >> to now have to consider alternatives. >>> > >> I find disturbing that committers fear to release and that goodwill to >>> > >> share >>> > >> features and code is killed by the process that should help publish >>> > them - >>> > >> not oppose them! >>> > >> >>> > >> I agree that a "release early, release often" scheme would help but >>> > I've no >>> > >> idea how to achieve this without a "release faster" mean. >>> > >> >>> > >> However, I ultimately suspect that the vested interest of some in >>> > promoting >>> > >> a hard, difficult and lengthy process relates to how their bills get >>> > payed >>> > >> and by whom; there is a huge difference in those of us doing this as a >>> > >> "goodwill hobby" - so to speak - because we feel it is good ethics to >>> > >> contribute back and those who make a living from it. Can't blame them >>> > for >>> > >> making sure their fees stay high by ensuring "hobbyists" don't get too >>> > >> efficient! (just kidding :-)) >>> > >> >>> > >> Cheers, >>> > >> Henrib >>> > >> >>> > >> -- >>> > >> View this message in context: >>> > >> >>> > >>> http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4148135.html >>> > >> Sent from the Commons - Dev mailing list archive at Nabble.com. >>> > >> >>> > >> --------------------------------------------------------------------- >>> > >> 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 >>> > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>> > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>> > > 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 >>> > >>> > >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>> 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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
