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

concurrent-ruby-edge defines sharp dependency #641

Closed
ares opened this Issue Mar 28, 2017 · 7 comments

Comments

4 participants
@ares

ares commented Mar 28, 2017

Having a sharp dependency makes specific edge version incompatible with newer version of concurrent-ruby. If you think about packaging, whenever concurrent-ruby is updated in lets say debian package, we need to find corresponding concurrent-ruby-edge (and hope there was a compatible version released).

What if the dependency was changed to >= so that it remains compatible with newer versions?
https://github.com/ruby-concurrency/concurrent-ruby/blob/master/concurrent-ruby-edge.gemspec#L31

@jdantonio

This comment has been minimized.

Show comment
Hide comment
@jdantonio

jdantonio Mar 28, 2017

Member

The tight coupling of versions was intentional. The goal was to always release updated versions of Edge and Ext whenever a new version of Core was released. The hope was to reduce the burden of developing and supporting Edge by strictly limiting its dependency with Core. Since Edge is experimental and not recommended for production, frequent churn is reasonable and expected. So we didn't consider that an issue (and in truth, Core doesn't get updated that often anyway). So "we need to find corresponding concurrent-ruby-edge (and hope there was a compatible version released)" is a non-issue. There will always be a compatible version released. That's how our build script works and that's the promise we've made to our community.

Having said that, if this system no longer works for the community then changes should be considered. That's up to @pitr-ch. I just wanted to explain the intent in case that helps your understanding.

Member

jdantonio commented Mar 28, 2017

The tight coupling of versions was intentional. The goal was to always release updated versions of Edge and Ext whenever a new version of Core was released. The hope was to reduce the burden of developing and supporting Edge by strictly limiting its dependency with Core. Since Edge is experimental and not recommended for production, frequent churn is reasonable and expected. So we didn't consider that an issue (and in truth, Core doesn't get updated that often anyway). So "we need to find corresponding concurrent-ruby-edge (and hope there was a compatible version released)" is a non-issue. There will always be a compatible version released. That's how our build script works and that's the promise we've made to our community.

Having said that, if this system no longer works for the community then changes should be considered. That's up to @pitr-ch. I just wanted to explain the intent in case that helps your understanding.

@ares

This comment has been minimized.

Show comment
Hide comment
@ares

ares Mar 29, 2017

Thanks a lot for explaining the reasons behind. Given there are probably less experimental features being added these days, I'd suggest considering merging to a single gem and use semantic versioning instead of releasing separate gems.

If there is a breaking change, people can always pin the older version. From maintainer point of view, 2 active branches can be kept, e.g. master for what is now edge and stable for what is core. Once the experimental feature is considered stable and generally accepted, it can be cherry-picked to stable branch.

ares commented Mar 29, 2017

Thanks a lot for explaining the reasons behind. Given there are probably less experimental features being added these days, I'd suggest considering merging to a single gem and use semantic versioning instead of releasing separate gems.

If there is a breaking change, people can always pin the older version. From maintainer point of view, 2 active branches can be kept, e.g. master for what is now edge and stable for what is core. Once the experimental feature is considered stable and generally accepted, it can be cherry-picked to stable branch.

@jdantonio

This comment has been minimized.

Show comment
Hide comment
@jdantonio

jdantonio Mar 29, 2017

Member

This problem may solve itself soon. @pitr-ch is working on the 2.0 release which merges much of Edge into Core. After that there may not be a need for Edge any more. Even if it's retained it will be much smaller than it is now, so there will be less of a concern with version incompatibilities. It may make sense to keep things as-is for now, and continue focussing on the 2.0 release.

Member

jdantonio commented Mar 29, 2017

This problem may solve itself soon. @pitr-ch is working on the 2.0 release which merges much of Edge into Core. After that there may not be a need for Edge any more. Even if it's retained it will be much smaller than it is now, so there will be less of a concern with version incompatibilities. It may make sense to keep things as-is for now, and continue focussing on the 2.0 release.

@pitr-ch pitr-ch closed this in 4dec493 Mar 29, 2017

pitr-ch added a commit that referenced this issue Mar 29, 2017

Merge pull request #642 from iNecas/less-dependency-strict-on-edge
Fixes #641 - remove sharp dependency edge -> core
@pitr-ch

This comment has been minimized.

Show comment
Hide comment
@pitr-ch

pitr-ch Mar 29, 2017

Member

For now I'll merge #642. concurrent-ruby has semver therefore edge should always work with a given major.minor version of concurrent-ruby.

Regarding other topics:

  • >= cannot be used since that would also imply that old edge will be compatible with c-r 2.0, which is unknown at this moment. I've used PR from @iNecas Thanks.
  • I'll release a 0.2.4 edge release with the relaxed dependencies.
  • I cannot merge the gems together. The versioning is not really compatible. Edge might force major bumps on the core too often which could get confusing for users. I would also like to keep making the edge features available for users to test before merging to core, which would not be easy to do if it's only in the master branch.
  • There will be a 1.1 release soon with merged promises from edge. Actors are staying behind for now though so @iNecas and @ares will still need edge.
  • 2.0 is in the making, but no idea when it'll be done yet.
Member

pitr-ch commented Mar 29, 2017

For now I'll merge #642. concurrent-ruby has semver therefore edge should always work with a given major.minor version of concurrent-ruby.

Regarding other topics:

  • >= cannot be used since that would also imply that old edge will be compatible with c-r 2.0, which is unknown at this moment. I've used PR from @iNecas Thanks.
  • I'll release a 0.2.4 edge release with the relaxed dependencies.
  • I cannot merge the gems together. The versioning is not really compatible. Edge might force major bumps on the core too often which could get confusing for users. I would also like to keep making the edge features available for users to test before merging to core, which would not be easy to do if it's only in the master branch.
  • There will be a 1.1 release soon with merged promises from edge. Actors are staying behind for now though so @iNecas and @ares will still need edge.
  • 2.0 is in the making, but no idea when it'll be done yet.

@pitr-ch pitr-ch added this to the 1.1.0 milestone Mar 29, 2017

@pitr-ch pitr-ch added the bug label Mar 29, 2017

@iNecas

This comment has been minimized.

Show comment
Hide comment
@iNecas

iNecas Mar 29, 2017

Contributor

Thanks @pitr-ch for updates (both as in "information sharing" as well as in rubygems :) The more we have in core the better. We count on living on the edge for a while still (please don't break it too often:)

Contributor

iNecas commented Mar 29, 2017

Thanks @pitr-ch for updates (both as in "information sharing" as well as in rubygems :) The more we have in core the better. We count on living on the edge for a while still (please don't break it too often:)

pitr-ch added a commit that referenced this issue Mar 29, 2017

@ares

This comment has been minimized.

Show comment
Hide comment
@ares

ares Mar 30, 2017

ares commented Mar 30, 2017

@pitr-ch

This comment has been minimized.

Show comment
Hide comment
@pitr-ch

pitr-ch Mar 30, 2017

Member

edge 0.2.4 released. @iNecas I'll try :) It will be in new readme for 1.1, but FYI edge versioning 0.x.y where x => incompatible changes, y => compatible changes.

Member

pitr-ch commented Mar 30, 2017

edge 0.2.4 released. @iNecas I'll try :) It will be in new readme for 1.1, but FYI edge versioning 0.x.y where x => incompatible changes, y => compatible changes.

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