commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [JEXL] Jexl 2.1?
Date Fri, 02 Dec 2011 21:51:04 GMT
On Fri, Dec 2, 2011 at 4:38 PM, sebb <sebbaz@gmail.com> wrote:

> On 2 December 2011 19:40, Gary Gregory <garydgregory@gmail.com> wrote:
> > On Fri, Dec 2, 2011 at 1:19 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 2 December 2011 17:52, Gary Gregory <garydgregory@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 <henrib@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-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message