commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [JEXL] Jexl 2.1?
Date Fri, 02 Dec 2011 20:08:27 GMT
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" <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
> 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 <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
>

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