You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2014/02/21 23:26:34 UTC
Time line for 5.0; was Re: Publicising methods in a GA release
On Fri, 2014-02-21 at 15:54 -0500, Gary Gregory wrote:
> Why not move trunk to 5.0 instead of 4.4 so we can drop all this deprecated
> code?
>
Major releases tend to be very disruptive. They are supposed to be. We
should consider doing 5.0 after 4.4 and taking it as an opportunity to
introduce some major features such as HTTP/2.0 support. However,
speaking from 4.0 experience it may take years to complete.
I would not do a major release just to drop deprecated code.
Oleg
> Gary
>
>
> On Fri, Feb 21, 2014 at 10:02 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
> > On Fri, 2014-02-21 at 14:49 +0000, sebb wrote:
> > > Surely this is equivalent to adding a new public method, which would be
> > allowed?
> > >
> > > We cannot remove the public qualifier, but I don't see why adding it
> > > could cause a problem.
> > >
> >
> > It is up to us to decide whether or not it is ok to add new methods in
> > bug fix releases x.y.Z, but so far I was always trying to keep them
> > fully compatible. In the stable release branch people should be able to
> > upgrade as well as downgrade without making any code changes.
> >
> > Oleg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Time line for 5.0; was Re: Publicising methods in a GA release
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-02-21 at 23:13 +0000, sebb wrote:
> On 21 February 2014 23:05, Gary Gregory <ga...@gmail.com> wrote:
> > On Fri, Feb 21, 2014 at 5:26 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> >> On Fri, 2014-02-21 at 15:54 -0500, Gary Gregory wrote:
> >> > Why not move trunk to 5.0 instead of 4.4 so we can drop all this
> >> deprecated
> >> > code?
> >> >
> >>
> >> Major releases tend to be very disruptive. They are supposed to be. We
> >> should consider doing 5.0 after 4.4 and taking it as an opportunity to
> >> introduce some major features such as HTTP/2.0 support. However,
> >> speaking from 4.0 experience it may take years to complete.
> >>
> >> I would not do a major release just to drop deprecated code.
>
> +1.
> We should not cause unnecessary grief for end-users.
>
> >>
> >
> > Perhaps, but you could start there, release early release often. 5.0 could
> > drop code, 5.1 could start adding features.
>
> Release early release often (RERO) does not make it easier for end-users.
>
> RERO may work well if the API is not being changed - i.e. only fixing bugs
> However the "release early" mantra often means that the API is
> half-baked - and then cannot be changed without causing grief to
> end-users
>
+1
This is precisely the problem. RERO works well as long as the APIs are
either very stable or do not need to be stable.
Once 5.0 APIs are frozen it will be quite difficult to introduce big
changes in 5.1. Let's keep 4.x line going for one or two more feature
releases and then consider doing 5.0.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Time line for 5.0; was Re: Publicising methods in a GA release
Posted by sebb <se...@gmail.com>.
On 21 February 2014 23:05, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Feb 21, 2014 at 5:26 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
>> On Fri, 2014-02-21 at 15:54 -0500, Gary Gregory wrote:
>> > Why not move trunk to 5.0 instead of 4.4 so we can drop all this
>> deprecated
>> > code?
>> >
>>
>> Major releases tend to be very disruptive. They are supposed to be. We
>> should consider doing 5.0 after 4.4 and taking it as an opportunity to
>> introduce some major features such as HTTP/2.0 support. However,
>> speaking from 4.0 experience it may take years to complete.
>>
>> I would not do a major release just to drop deprecated code.
+1.
We should not cause unnecessary grief for end-users.
>>
>
> Perhaps, but you could start there, release early release often. 5.0 could
> drop code, 5.1 could start adding features.
Release early release often (RERO) does not make it easier for end-users.
RERO may work well if the API is not being changed - i.e. only fixing bugs
However the "release early" mantra often means that the API is
half-baked - and then cannot be changed without causing grief to
end-users
> Gary
>
>
>>
>> Oleg
>>
>> > Gary
>> >
>> >
>> > On Fri, Feb 21, 2014 at 10:02 AM, Oleg Kalnichevski <olegk@apache.org
>> >wrote:
>> >
>> > > On Fri, 2014-02-21 at 14:49 +0000, sebb wrote:
>> > > > Surely this is equivalent to adding a new public method, which would
>> be
>> > > allowed?
>> > > >
>> > > > We cannot remove the public qualifier, but I don't see why adding it
>> > > > could cause a problem.
>> > > >
>> > >
>> > > It is up to us to decide whether or not it is ok to add new methods in
>> > > bug fix releases x.y.Z, but so far I was always trying to keep them
>> > > fully compatible. In the stable release branch people should be able to
>> > > upgrade as well as downgrade without making any code changes.
>> > >
>> > > Oleg
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > > For additional commands, e-mail: dev-help@hc.apache.org
>> > >
>> > >
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Time line for 5.0; was Re: Publicising methods in a GA release
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Feb 21, 2014 at 5:26 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2014-02-21 at 15:54 -0500, Gary Gregory wrote:
> > Why not move trunk to 5.0 instead of 4.4 so we can drop all this
> deprecated
> > code?
> >
>
> Major releases tend to be very disruptive. They are supposed to be. We
> should consider doing 5.0 after 4.4 and taking it as an opportunity to
> introduce some major features such as HTTP/2.0 support. However,
> speaking from 4.0 experience it may take years to complete.
>
> I would not do a major release just to drop deprecated code.
>
Perhaps, but you could start there, release early release often. 5.0 could
drop code, 5.1 could start adding features.
Gary
>
> Oleg
>
> > Gary
> >
> >
> > On Fri, Feb 21, 2014 at 10:02 AM, Oleg Kalnichevski <olegk@apache.org
> >wrote:
> >
> > > On Fri, 2014-02-21 at 14:49 +0000, sebb wrote:
> > > > Surely this is equivalent to adding a new public method, which would
> be
> > > allowed?
> > > >
> > > > We cannot remove the public qualifier, but I don't see why adding it
> > > > could cause a problem.
> > > >
> > >
> > > It is up to us to decide whether or not it is ok to add new methods in
> > > bug fix releases x.y.Z, but so far I was always trying to keep them
> > > fully compatible. In the stable release branch people should be able to
> > > upgrade as well as downgrade without making any code changes.
> > >
> > > Oleg
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory