On Fri, Dec 2, 2011 at 4:38 PM, sebb <seb...@gmail.com> wrote: > On 2 December 2011 19:40, 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 > > If the new features can be released without requiring code changes, > then surely that is simpler? >
True, but (see below). > > > 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.) > > Exactly, 3.x is more expensive than 2.x, so we should try to avoid > unnecessary breakages. > The key here is "unnecessary" which will be subjective in some cases. Gary > > 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 > > -- 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
