ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: [DiSCUSS] Incompatible changes
Date Wed, 26 Aug 2015 18:01:24 GMT
Yup, big +1's on both points: the versioning schema (thanks a bunch for
digging it up, Brane!) and sticking to a stricter compatibility rules.
Integers are cheap and abundant, but conveying the clear message that say 2.0
isn't compatible with 1.4 because of XYZ in hadoop module is important. It is
a far clearer than "2.0 and 1.4 are fine, except that hadoop module isn't
because of XYZ".

Regards,
  Cos

On Wed, Aug 26, 2015 at 07:35PM, Branko ─îibej wrote:
> On 26.08.2015 15:56, Vladimir Ozerov wrote:
> > One more important thing here - distinction between overall compatibility
> > and module compatibility. We may face serious bugs which severely affects
> > single module/subsystem and fix will break backward ocmpatibility only on
> > of that module.
> > E.g. currently in IGFS file might be locked for write forever in case of
> > abrupt shutdown of a node from which this write were initiated. The only
> > way to fix this reliably is to change an object which travels over a wire,
> > what might break backward compatibility.
> >
> > May be we should be able to relax compatibility requirements on module
> > level sometimes?
> 
> It's better to have the same kind of versioning rules for the wire
> protocol, too; a capability discovery can tell you when you can use a
> new kind of message.
> 
> I don't know how important this kind of compatibility is for Ignite;
> it's extremely important in Subversion, because it allows independent
> updates/rollbacks of servers and clients.
> 
> Or you can avoid the compatibility issue by calling the fixed protocol
> Ignite 2.0. :)
> 
> -- Brane
> 
> 
> On Wed, Aug 26, 2015 at 10:40 AM, Branko ─îibej <brane@apache.org> wrote:
> >> On 26.08.2015 08:54, Alexey Goncharuk wrote:
> >>> This particular change does not break the compatibility (a new method is
> >>> being added to the public API), however I am +1 for adding these
> >> principles
> >>> to the dev documentation.
> >> Way back when Ignite was still a podling I pointed out this:
> >>
> >>     http://apr.apache.org/versioning.html
> >>
> >>
> >> http://subversion.apache.org/docs/community-guide/releasing.html#release-compat
> >>
> >> As I did then, I suggest we either refer to these docs directly, or copy
> >> over essentially the same principles to our docs.
> >>
> >> -- Brane
> >>
> >>
> >>> 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <cos@apache.org>:
> >>>
> >>>> Reading this I thought it would be a good idea to articulate some of
the
> >>>> possible challenges that we will face in the future.
> >>>>
> >>>> Say, how we add/release incompatible changes like API modifications,
> >>>> deprecations, etc. Say, introduction of incompatible changes shouldn't
> >> be
> >>>> done
> >>>> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes
to
> >>>> mind as
> >>>> a biggest screw-up of the kind. Hence, to avoid being a laughing stock
> >> of
> >>>> the
> >>>> world's developers it would makes perfect sense to have some of these
> >>>> seemingly obvious principles either written or referred among other
> >>>> development resources.
> >>>>
> >>>> Thoughts?
> >>>>     Cos
> >>>>
> >>>> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
> >>>>> Ken, I added comments to the pull request on GitHub.
> >>>>>
> >>>>> I would prefer another committer to review this pull request as
well
> >>>> since
> >>>>> public API is being changed (Dmitriy, Yakov?)
> >>>>>
> >>>>> --
> >>>>> AG
> >>>>>
> >>>>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <kcheng.mvp@gmail.com>:
> >>>>>
> >>>>>> Hi Devs,
> >>>>>>
> >>>>>> Anybody can help me to do a code review for PR
> >>>>>>
> >>>>>> https://github.com/apache/ignite/pull/35
> >>>>>>
> >>>>>> Thanks,
> >>>>>> kcheng
> >>>>>>
> >>
> 

Mime
View raw message