New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HangFire.Redis incompatible with ServiceStack 4.0 #122

Closed
peters opened this Issue Jun 12, 2014 · 25 comments

Comments

@peters

peters commented Jun 12, 2014

Unable to install if using ServiceStack.Redis.

It's no big deal for us since we can just fallback to Sql Azure but this should be fixed anyway.

@peters peters changed the title from Hangfire.Redis to Hangfire.Redis incompatible with Servicestack 4.0 Jun 12, 2014

@odinserj

This comment has been minimized.

Show comment
Hide comment
@odinserj

odinserj Jun 12, 2014

Member

Yep, and since ServiceStack 4.0 uses another licensing strategy, there should be both support for 3.x and 4.x versions. Or maybe Redis storage should use StackExchange.Redis library instead. I'll choose the solution, but a bit later.

Member

odinserj commented Jun 12, 2014

Yep, and since ServiceStack 4.0 uses another licensing strategy, there should be both support for 3.x and 4.x versions. Or maybe Redis storage should use StackExchange.Redis library instead. I'll choose the solution, but a bit later.

@odinserj odinserj changed the title from Hangfire.Redis incompatible with Servicestack 4.0 to HangFire.Redis incompatible with Servicestack 4.0 Jun 12, 2014

@odinserj odinserj changed the title from HangFire.Redis incompatible with Servicestack 4.0 to HangFire.Redis incompatible with ServiceStack 4.0 Jun 12, 2014

@odinserj odinserj added this to the vFuture milestone Jun 12, 2014

@odinserj odinserj added the redis label Jul 2, 2014

@Tazer

This comment has been minimized.

Show comment
Hide comment
@Tazer

Tazer Aug 26, 2014

Any plans on making the switch soon ?

Tazer commented Aug 26, 2014

Any plans on making the switch soon ?

@Caldas

This comment has been minimized.

Show comment
Hide comment
@Caldas

Caldas Aug 26, 2014

ServiceStack 4 has a different license. I don't think it's a good idea to use it

-----Mensagem Original-----
De: "Patrik" notifications@github.com
Enviada em: ‎26/‎08/‎2014 11:49
Para: "HangfireIO/Hangfire" Hangfire@noreply.github.com
Assunto: Re: [Hangfire] HangFire.Redis incompatible with ServiceStack 4.0(#122)

Any plans on making the switch soon ?

Reply to this email directly or view it on GitHub.

Caldas commented Aug 26, 2014

ServiceStack 4 has a different license. I don't think it's a good idea to use it

-----Mensagem Original-----
De: "Patrik" notifications@github.com
Enviada em: ‎26/‎08/‎2014 11:49
Para: "HangfireIO/Hangfire" Hangfire@noreply.github.com
Assunto: Re: [Hangfire] HangFire.Redis incompatible with ServiceStack 4.0(#122)

Any plans on making the switch soon ?

Reply to this email directly or view it on GitHub.

@Tazer

This comment has been minimized.

Show comment
Hide comment
@Tazer

Tazer Aug 26, 2014

@Caldas I'm with you on that,

I was referring to switching to StackExchange.Redis

Tazer commented Aug 26, 2014

@Caldas I'm with you on that,

I was referring to switching to StackExchange.Redis

@ghuntley

This comment has been minimized.

Show comment
Hide comment
@ghuntley

ghuntley Aug 31, 2014

Hmm. Ran into this today for now just using SQL Azure as workaround. Have SS license and I'm using SSv4.Redis but if you need to go StackExchange.Redis then either way. - Subscribing.

ghuntley commented Aug 31, 2014

Hmm. Ran into this today for now just using SQL Azure as workaround. Have SS license and I'm using SSv4.Redis but if you need to go StackExchange.Redis then either way. - Subscribing.

@kieranbenton

This comment has been minimized.

Show comment
Hide comment
@kieranbenton

kieranbenton Sep 7, 2014

I would also +1 for using StackExchange.Redis, its had some initial teething problems but it is now very stable and very fast, as well as having barely any dependencies.

Anything we can do to help @odinserj?

kieranbenton commented Sep 7, 2014

I would also +1 for using StackExchange.Redis, its had some initial teething problems but it is now very stable and very fast, as well as having barely any dependencies.

Anything we can do to help @odinserj?

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Sep 27, 2014

👍 For the switch. I've been porting my projects to use StackExchange.Redis.

I pulled down Hangfire to see if I could start ripping it apart to use StackExchange.Redis. The most glaring problem to port it over will be the fact that currently Hangfire uses blocking pop/push commands, which StackExchange.Redis doesn't support because of multiplexing.

I'd be glad to help port this over if we can collectively decide how to implement this.

TheCloudlessSky commented Sep 27, 2014

👍 For the switch. I've been porting my projects to use StackExchange.Redis.

I pulled down Hangfire to see if I could start ripping it apart to use StackExchange.Redis. The most glaring problem to port it over will be the fact that currently Hangfire uses blocking pop/push commands, which StackExchange.Redis doesn't support because of multiplexing.

I'd be glad to help port this over if we can collectively decide how to implement this.

@sjwoodard

This comment has been minimized.

Show comment
Hide comment
@sjwoodard

sjwoodard Sep 28, 2014

@TheCloudlessSky, I'm able to help as well.

sjwoodard commented Sep 28, 2014

@TheCloudlessSky, I'm able to help as well.

@sqmgh

This comment has been minimized.

Show comment
Hide comment
@sqmgh

sqmgh Oct 15, 2014

I haven't gone through all the code to see for certain, but if it's only using the blocking pop/push to wait for the next item to process, why not use pub/sub a method similar to what is described on the linked StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth having. Even if it's only in addition to the ServiceStack one.

sqmgh commented Oct 15, 2014

I haven't gone through all the code to see for certain, but if it's only using the blocking pop/push to wait for the next item to process, why not use pub/sub a method similar to what is described on the linked StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth having. Even if it's only in addition to the ServiceStack one.

@kieranbenton

This comment has been minimized.

Show comment
Hide comment
@kieranbenton

kieranbenton Oct 20, 2014

Sounds reasonable to me, is there any appetite to getting this done? I'd
happily lend some time to this.

On 15 October 2014 21:02, sqmgh notifications@github.com wrote:

I haven't gone through all the code to see for certain, but if it's only
using the blocking pop/push to wait for the next item to process, why not
use pub/sub a method similar to what is described on the linked
StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth
having. Even if it's only in addition to the ServiceStack one.


Reply to this email directly or view it on GitHub
#122 (comment).

kieranbenton commented Oct 20, 2014

Sounds reasonable to me, is there any appetite to getting this done? I'd
happily lend some time to this.

On 15 October 2014 21:02, sqmgh notifications@github.com wrote:

I haven't gone through all the code to see for certain, but if it's only
using the blocking pop/push to wait for the next item to process, why not
use pub/sub a method similar to what is described on the linked
StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth
having. Even if it's only in addition to the ServiceStack one.


Reply to this email directly or view it on GitHub
#122 (comment).

@sergeyzwezdin

This comment has been minimized.

Show comment
Hide comment
@sergeyzwezdin

sergeyzwezdin Nov 7, 2014

Contributor

Does that means that if I use redis as a stroage for hangfire I have to pay for StackExchange?
@odinserj could you explain?

Contributor

sergeyzwezdin commented Nov 7, 2014

Does that means that if I use redis as a stroage for hangfire I have to pay for StackExchange?
@odinserj could you explain?

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Nov 7, 2014

@sergun No, you shouldn't have to since the current version depends on ServiceStack.Redis < 4.0 packages which do not require a commercial license.

TheCloudlessSky commented Nov 7, 2014

@sergun No, you shouldn't have to since the current version depends on ServiceStack.Redis < 4.0 packages which do not require a commercial license.

@sjwoodard

This comment has been minimized.

Show comment
Hide comment
@sjwoodard

sjwoodard Nov 7, 2014

Hangfire uses ServiceStack v3, which is under the BSD license. @sergun said "pay for StackExchange", but StackExchange, which is under the MIT license, is not used in Hangfire. Earlier in this thread we were discussing switching Hangfire from using ServiceStack to StackExchange, but I'm not sure what @odinserj thinks.

sjwoodard commented Nov 7, 2014

Hangfire uses ServiceStack v3, which is under the BSD license. @sergun said "pay for StackExchange", but StackExchange, which is under the MIT license, is not used in Hangfire. Earlier in this thread we were discussing switching Hangfire from using ServiceStack to StackExchange, but I'm not sure what @odinserj thinks.

@sergeyzwezdin

This comment has been minimized.

Show comment
Hide comment
@sergeyzwezdin

sergeyzwezdin Nov 7, 2014

Contributor

@TheCloudlessSky @sjwoodard Thanks for expanation guys.

Regarding migration to StackExchange — I'd completely agree with it. It would be better as for me :-)

Contributor

sergeyzwezdin commented Nov 7, 2014

@TheCloudlessSky @sjwoodard Thanks for expanation guys.

Regarding migration to StackExchange — I'd completely agree with it. It would be better as for me :-)

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Nov 7, 2014

@sjwoodard Sorry, yes, he did mean StackExchange. I've always found the the two have such similar names that dyslexia kicks in...😵

TheCloudlessSky commented Nov 7, 2014

@sjwoodard Sorry, yes, he did mean StackExchange. I've always found the the two have such similar names that dyslexia kicks in...😵

@odinserj odinserj added the a: pro label Nov 15, 2014

@odinserj

This comment has been minimized.

Show comment
Hide comment
@odinserj

odinserj Nov 15, 2014

Member

This feature is implemented in a new version of Hangfire Redis library, you can look the details in this blog post.

Migration to StackExchange.Redis is unnecessary, and Hangfire.Pro.Redis uses ILMerge to internalize ServiceStack libraries to the assembly. Since there is no any dependency now, you can use any ServiceStack version in your project.

Member

odinserj commented Nov 15, 2014

This feature is implemented in a new version of Hangfire Redis library, you can look the details in this blog post.

Migration to StackExchange.Redis is unnecessary, and Hangfire.Pro.Redis uses ILMerge to internalize ServiceStack libraries to the assembly. Since there is no any dependency now, you can use any ServiceStack version in your project.

@odinserj odinserj closed this Nov 15, 2014

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Nov 15, 2014

What the heck is up with .NET developers and commercializing their libraries and dropping support for things (ServiceStack, RavenDB, Hangfire etc)? The idea of FOSS seems to be lost in this community...

This is bad news, in my opinion. I don't disagree with you offering a commercial version (you should be getting paid for your hard work), but there are plenty of good reasons to move away from ServiceStack.Redis and keep the rest of the project FOSS. I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

TheCloudlessSky commented Nov 15, 2014

What the heck is up with .NET developers and commercializing their libraries and dropping support for things (ServiceStack, RavenDB, Hangfire etc)? The idea of FOSS seems to be lost in this community...

This is bad news, in my opinion. I don't disagree with you offering a commercial version (you should be getting paid for your hard work), but there are plenty of good reasons to move away from ServiceStack.Redis and keep the rest of the project FOSS. I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

@odinserj

This comment has been minimized.

Show comment
Hide comment
@odinserj

odinserj Nov 15, 2014

Member

@TheCloudlessSky, I've introduced commercialization to have a chance to support the project in a long-term. My life is not stable enough to regularly work on projects without any commercialization for a long time. Perhaps there are better solutions for Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my decisions are acceptable, and I understand the consequences. It is also unclear for me, what do you exactly mean by the idea of FOSS (please use less abstractive wording). But I'm sure there will be no idea at all for a project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So why we are talking about it?

Member

odinserj commented Nov 15, 2014

@TheCloudlessSky, I've introduced commercialization to have a chance to support the project in a long-term. My life is not stable enough to regularly work on projects without any commercialization for a long time. Perhaps there are better solutions for Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my decisions are acceptable, and I understand the consequences. It is also unclear for me, what do you exactly mean by the idea of FOSS (please use less abstractive wording). But I'm sure there will be no idea at all for a project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So why we are talking about it?

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Nov 15, 2014

Actually, I have very much offered to help (see above). I would be glad to
contribute to a free and open source (FOSS) version of Redis storage for
Hangfire. And it is probably what I will do. Check my profile, I maintain
several projects that use Redis as the storage.

Like I said, I'm not at all against you commercializing your work (offering
paid support). I just find the .NET community goes about it wrong (dropping
open source support for existing libraries and/or making them no longer
open source). It happened with RavenDB, ServiceStack and now Hangfire (and
I'm sure plenty of others). Its not the true definition of open source.

Anyways, I'm definitely capable and willing to port this with
StackExchange.Redis. Thanks!
On 2014-11-15 10:41 AM, "Sergey Odinokov" notifications@github.com wrote:

@TheCloudlessSky https://github.com/TheCloudlessSky, I've introduced
commercialization to have a chance to support the project in a long-term.
My life is not stable enough to regularly work on projects without any
commercialization for a long time. Perhaps there are better solutions for
Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my
decisions are acceptable, and I understand the consequences. It is also
unclear for me, what do you exactly mean by the idea of FOSS (please use
less abstractive wording). But I'm sure there will be no idea at all for a
project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library
that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So
why we are talking about it?


Reply to this email directly or view it on GitHub
#122 (comment).

TheCloudlessSky commented Nov 15, 2014

Actually, I have very much offered to help (see above). I would be glad to
contribute to a free and open source (FOSS) version of Redis storage for
Hangfire. And it is probably what I will do. Check my profile, I maintain
several projects that use Redis as the storage.

Like I said, I'm not at all against you commercializing your work (offering
paid support). I just find the .NET community goes about it wrong (dropping
open source support for existing libraries and/or making them no longer
open source). It happened with RavenDB, ServiceStack and now Hangfire (and
I'm sure plenty of others). Its not the true definition of open source.

Anyways, I'm definitely capable and willing to port this with
StackExchange.Redis. Thanks!
On 2014-11-15 10:41 AM, "Sergey Odinokov" notifications@github.com wrote:

@TheCloudlessSky https://github.com/TheCloudlessSky, I've introduced
commercialization to have a chance to support the project in a long-term.
My life is not stable enough to regularly work on projects without any
commercialization for a long time. Perhaps there are better solutions for
Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my
decisions are acceptable, and I understand the consequences. It is also
unclear for me, what do you exactly mean by the idea of FOSS (please use
less abstractive wording). But I'm sure there will be no idea at all for a
project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library
that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So
why we are talking about it?


Reply to this email directly or view it on GitHub
#122 (comment).

@odinserj

This comment has been minimized.

Show comment
Hide comment
@odinserj

odinserj Nov 16, 2014

Member

I just find the .NET community goes about it wrong (dropping open source support for existing libraries and/or making them no longer open source). It happened with RavenDB, ServiceStack and now Hangfire (and I'm sure plenty of others). Its not the true definition of open source.

On the other hand, other open-source background job systems for .NET like Resque.NET, Linger, C# Resque, Roque, WebBackgrounder, Revalee, Burden, awesome Blue Collar, powerful Quartz.NET have low or very low activity (like other 95% OSS projects) and many of them may be considered dead. Open-source, but dead.

Open source is really hard. And I simply can't allow circumstances to destroy the work done. This is my first open-source project, and I consider the risk of project death is very high since the very beginning.

Member

odinserj commented Nov 16, 2014

I just find the .NET community goes about it wrong (dropping open source support for existing libraries and/or making them no longer open source). It happened with RavenDB, ServiceStack and now Hangfire (and I'm sure plenty of others). Its not the true definition of open source.

On the other hand, other open-source background job systems for .NET like Resque.NET, Linger, C# Resque, Roque, WebBackgrounder, Revalee, Burden, awesome Blue Collar, powerful Quartz.NET have low or very low activity (like other 95% OSS projects) and many of them may be considered dead. Open-source, but dead.

Open source is really hard. And I simply can't allow circumstances to destroy the work done. This is my first open-source project, and I consider the risk of project death is very high since the very beginning.

@devmondo

This comment has been minimized.

Show comment
Hide comment
@devmondo

devmondo Nov 16, 2014

Contributor

if you have stuck with .Net enough you know that background tasks functionality and solutions are very hard or lacking and what @odinserj did is just amazing in terms of simplicity and stability and i for one support all the way his notion of commercialization of his product, i really dont believe in freemium model, if @odinserj spends 50 % of his daily time on working on Hangfire for free, where would he earn living from? if he wants to spend time on answering you, fix bug for you, add new awesome features, how much time he needs to spend on that ? plus if we look at other similar commercial .Net solution we would see that the price of Hangfire is reasonable, specially that the license gives you unlimited usage on servers and domains.

but with that being said i really wish @odinserj rethink the pricing model, 500 $ seems really steep, specially that now customers are like sheep falling for the cloud model and its pricing, specially something like Azure where it offers Hangfire functionality among mired of other integrated services for what looks like a cheap price.

if i may suggest the following

  • 250 $ or 300 $ as subscription price
    -make it used on unlimited servers and domains
    -mention it works with ASP.Net Vnext on Linux and Mac
    -improve Docs and Samples

change the current subscription page details to reflect that clearly, as the current one you have to go through reading the large confusing (for poor souls like me) page.

Hangfire is a precious Gift to us given by @odinserj and the way it made my workflow simpler alone makes me pay to support the efforts.

Contributor

devmondo commented Nov 16, 2014

if you have stuck with .Net enough you know that background tasks functionality and solutions are very hard or lacking and what @odinserj did is just amazing in terms of simplicity and stability and i for one support all the way his notion of commercialization of his product, i really dont believe in freemium model, if @odinserj spends 50 % of his daily time on working on Hangfire for free, where would he earn living from? if he wants to spend time on answering you, fix bug for you, add new awesome features, how much time he needs to spend on that ? plus if we look at other similar commercial .Net solution we would see that the price of Hangfire is reasonable, specially that the license gives you unlimited usage on servers and domains.

but with that being said i really wish @odinserj rethink the pricing model, 500 $ seems really steep, specially that now customers are like sheep falling for the cloud model and its pricing, specially something like Azure where it offers Hangfire functionality among mired of other integrated services for what looks like a cheap price.

if i may suggest the following

  • 250 $ or 300 $ as subscription price
    -make it used on unlimited servers and domains
    -mention it works with ASP.Net Vnext on Linux and Mac
    -improve Docs and Samples

change the current subscription page details to reflect that clearly, as the current one you have to go through reading the large confusing (for poor souls like me) page.

Hangfire is a precious Gift to us given by @odinserj and the way it made my workflow simpler alone makes me pay to support the efforts.

@TheCloudlessSky

This comment has been minimized.

Show comment
Hide comment
@TheCloudlessSky

TheCloudlessSky Nov 16, 2014

@devmondo I think you've misunderstood what I'm arguing here. I'm not against letting @odinserj get paid for his work. I am against the .NET community not fully embracing open source. ServiceStack.Redis took a turn for the worse because of their licensing changes and dropping of true open source.

@odinserj We're still arguing about different things. I support you commercializing things such as support, "extra features", etc to get paid for what you're doing and keeping the project alive. But I am against you dropping support for a library that already exists as open source (or switching it over to a commercial library). I have never said open source was easy, but you're damaging the .NET open source community by dropping this library from open source.

TheCloudlessSky commented Nov 16, 2014

@devmondo I think you've misunderstood what I'm arguing here. I'm not against letting @odinserj get paid for his work. I am against the .NET community not fully embracing open source. ServiceStack.Redis took a turn for the worse because of their licensing changes and dropping of true open source.

@odinserj We're still arguing about different things. I support you commercializing things such as support, "extra features", etc to get paid for what you're doing and keeping the project alive. But I am against you dropping support for a library that already exists as open source (or switching it over to a commercial library). I have never said open source was easy, but you're damaging the .NET open source community by dropping this library from open source.

@odinserj

This comment has been minimized.

Show comment
Hide comment
@odinserj

odinserj Nov 17, 2014

Member

Hi, @devmondo. I'll be improving each part of the project, including the pricing page. It is hard for me too :) Regarding the pricing model – I thought about it for some monthes, and it suits current context.

@TheCloudlessSky,

you're damaging the .NET open source community

No, really?

Member

odinserj commented Nov 17, 2014

Hi, @devmondo. I'll be improving each part of the project, including the pricing page. It is hard for me too :) Regarding the pricing model – I thought about it for some monthes, and it suits current context.

@TheCloudlessSky,

you're damaging the .NET open source community

No, really?

@devmondo

This comment has been minimized.

Show comment
Hide comment
@devmondo

devmondo Nov 17, 2014

Contributor

@odinserj long time i did not talk to you, i am a father now and barley can breath :)

regarding pricing, i wont argue much with you, you should get money and feel satisfied, but i suggest that Async, Continuation, Parallel features should be in the free version, and stuff like Performance Counters, Replication and Mission Critical features and urgent support should be in the pro.

why i am suggesting the above, because the way i see it, it is going to give you more marketing, as the more users will use it the more the word will spread, and as you know when users sites grow, they will need more enterprise features, and because they are using Hangfire already, they will naturally eventually pay for the pro and will not look for alternative solution

trust me this is how smart Americans do business, they are flexible and know how to lure customers in, while rest of us Russians, Asians and rest of the world sometimes do it all or nothing :)

besides i think that you will benefit more if you open a survey and user voice so us users will give you our opinion about features and pricing we are willing to pay for Pro, this will give you scientifically practical estimation of how people want to pay for your product and you will get more guarantee in terms of the best business model you should follow.

just my 2 Rubles :)

Contributor

devmondo commented Nov 17, 2014

@odinserj long time i did not talk to you, i am a father now and barley can breath :)

regarding pricing, i wont argue much with you, you should get money and feel satisfied, but i suggest that Async, Continuation, Parallel features should be in the free version, and stuff like Performance Counters, Replication and Mission Critical features and urgent support should be in the pro.

why i am suggesting the above, because the way i see it, it is going to give you more marketing, as the more users will use it the more the word will spread, and as you know when users sites grow, they will need more enterprise features, and because they are using Hangfire already, they will naturally eventually pay for the pro and will not look for alternative solution

trust me this is how smart Americans do business, they are flexible and know how to lure customers in, while rest of us Russians, Asians and rest of the world sometimes do it all or nothing :)

besides i think that you will benefit more if you open a survey and user voice so us users will give you our opinion about features and pricing we are willing to pay for Pro, this will give you scientifically practical estimation of how people want to pay for your product and you will get more guarantee in terms of the best business model you should follow.

just my 2 Rubles :)

@ghuntley

This comment has been minimized.

Show comment
Hide comment
@ghuntley

ghuntley Nov 17, 2014

On 17 November 2014 23:35, devmondo notifications@github.com wrote:

regarding pricing, i wont argue much with you, you should get money and
feel satisfied, but i suggest that Async, Continuation, Parallel features
should be in the free version, and stuff like Performance Counters,
Replication and Mission Critical features and urgent support should be in
the pro.
Completely agree with above.

ghuntley commented Nov 17, 2014

On 17 November 2014 23:35, devmondo notifications@github.com wrote:

regarding pricing, i wont argue much with you, you should get money and
feel satisfied, but i suggest that Async, Continuation, Parallel features
should be in the free version, and stuff like Performance Counters,
Replication and Mission Critical features and urgent support should be in
the pro.
Completely agree with above.

@odinserj odinserj removed this from the vFuture milestone Jun 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment