Support for multiple versions of a binding?

[Gregory Chanan <gc...@cloudera.com>]

Do any of our plugin/bindings have support for multiple versions of the
same components?  I'd like to add some support for Solr 5, but it's not
compatible with Solr4.  So, I guess I could bump the Solr version but that
would seem to mean we would need to bump the Sentry major version.

There are a few different ways to handle this without bumping a Sentry
major version, e.g. build explicit different artifacts for each version or
a compatibility layer that figures out which version it is running against
using reflection.  Not purposing any technical solution at this point,
though, just seeing if anyone has thought about this before wrt Sentry?

Thanks,
Greg

Re: Support for multiple versions of a binding?

[Lenni Kuff <ls...@cloudera.com>]

+1 to the approach the Dapeng outlined. This should minimize problems with
test duplication and make it very explicit which version of the solr
binding is being built / tested.

Thanks,
Lenni

On Tue, Nov 24, 2015 at 11:54 AM, Gregory Chanan <gc...@cloudera.com>
wrote:

> That makes sense to me, I'll try that out and see how it goes.
>
> Greg
>
> On Mon, Nov 23, 2015 at 11:09 PM, Sun, Dapeng <da...@intel.com>
> wrote:
>
> > Hi Greg,
> >
> > I think we can resolve these kind of problem via " build explicit
> > different artifacts for each version "
> >
> > For your case, we may need:
> > 1.Add a new maven module solr-binding for higher version solr.
> > 2.Separate old solr-binding to solr-binding-common and
> > solr-binding-old-version
> > 3.For the E2E unit test, we can also Separate old-solr-e2e to common,
> > old-version and new-version.
> > We can use maven profile to activate other minor version, by default they
> > are inactive.
> >
> > Using reflection or putting the both two implementation to same package,
> I
> > think they are also okay, but with the increase of version, the code will
> > become more and more complicated.
> >
> > Regards
> > Dapeng
> >
> > -----Original Message-----
> > From: Gregory Chanan [mailto:gchanan@cloudera.com]
> > Sent: Thursday, November 19, 2015 9:43 AM
> > To: dev@sentry.incubator.apache.org
> > Subject: Support for multiple versions of a binding?
> >
> > Do any of our plugin/bindings have support for multiple versions of the
> > same components?  I'd like to add some support for Solr 5, but it's not
> > compatible with Solr4.  So, I guess I could bump the Solr version but
> that
> > would seem to mean we would need to bump the Sentry major version.
> >
> > There are a few different ways to handle this without bumping a Sentry
> > major version, e.g. build explicit different artifacts for each version
> or
> > a compatibility layer that figures out which version it is running
> against
> > using reflection.  Not purposing any technical solution at this point,
> > though, just seeing if anyone has thought about this before wrt Sentry?
> >
> > Thanks,
> > Greg
> >
>

Re: Support for multiple versions of a binding?

[Gregory Chanan <gc...@cloudera.com>]

That makes sense to me, I'll try that out and see how it goes.

Greg

On Mon, Nov 23, 2015 at 11:09 PM, Sun, Dapeng <da...@intel.com> wrote:

> Hi Greg,
>
> I think we can resolve these kind of problem via " build explicit
> different artifacts for each version "
>
> For your case, we may need:
> 1.Add a new maven module solr-binding for higher version solr.
> 2.Separate old solr-binding to solr-binding-common and
> solr-binding-old-version
> 3.For the E2E unit test, we can also Separate old-solr-e2e to common,
> old-version and new-version.
> We can use maven profile to activate other minor version, by default they
> are inactive.
>
> Using reflection or putting the both two implementation to same package, I
> think they are also okay, but with the increase of version, the code will
> become more and more complicated.
>
> Regards
> Dapeng
>
> -----Original Message-----
> From: Gregory Chanan [mailto:gchanan@cloudera.com]
> Sent: Thursday, November 19, 2015 9:43 AM
> To: dev@sentry.incubator.apache.org
> Subject: Support for multiple versions of a binding?
>
> Do any of our plugin/bindings have support for multiple versions of the
> same components?  I'd like to add some support for Solr 5, but it's not
> compatible with Solr4.  So, I guess I could bump the Solr version but that
> would seem to mean we would need to bump the Sentry major version.
>
> There are a few different ways to handle this without bumping a Sentry
> major version, e.g. build explicit different artifacts for each version or
> a compatibility layer that figures out which version it is running against
> using reflection.  Not purposing any technical solution at this point,
> though, just seeing if anyone has thought about this before wrt Sentry?
>
> Thanks,
> Greg
>

RE: Support for multiple versions of a binding?

["Sun, Dapeng" <da...@intel.com>]

Hi Greg,

I think we can resolve these kind of problem via " build explicit different artifacts for each version "

For your case, we may need: 
1.Add a new maven module solr-binding for higher version solr.
2.Separate old solr-binding to solr-binding-common and solr-binding-old-version
3.For the E2E unit test, we can also Separate old-solr-e2e to common, old-version and new-version. 
We can use maven profile to activate other minor version, by default they are inactive.

Using reflection or putting the both two implementation to same package, I think they are also okay, but with the increase of version, the code will become more and more complicated.

Regards
Dapeng

-----Original Message-----
From: Gregory Chanan [mailto:gchanan@cloudera.com] 
Sent: Thursday, November 19, 2015 9:43 AM
To: dev@sentry.incubator.apache.org
Subject: Support for multiple versions of a binding?

Do any of our plugin/bindings have support for multiple versions of the same components?  I'd like to add some support for Solr 5, but it's not compatible with Solr4.  So, I guess I could bump the Solr version but that would seem to mean we would need to bump the Sentry major version.

There are a few different ways to handle this without bumping a Sentry major version, e.g. build explicit different artifacts for each version or a compatibility layer that figures out which version it is running against using reflection.  Not purposing any technical solution at this point, though, just seeing if anyone has thought about this before wrt Sentry?

Thanks,
Greg