Skip to content
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

Cats 1.0.0 packaging #1682

Closed
kailuowang opened this issue May 18, 2017 · 7 comments · Fixed by #1758
Closed

Cats 1.0.0 packaging #1682

kailuowang opened this issue May 18, 2017 · 7 comments · Fixed by #1758
Milestone

Comments

@kailuowang
Copy link
Contributor

This is an issue consolidating all the packaging/publish related issues #1656, #1184, #472 and #592.
There are three separate decisions that are sort of related. It may make sense to decide on all of them all together. Here is the revised version of @BennyHill's summarization in this comment (I added more description for context)

  1. Shall we continue publishing the current cats bundle which includes cats-laws and cats-free?
    The cats-laws includes a scalacheck dependency which surprises people.

Options are:
a) Keep as-is
b) Keep as-is but minus test libs
c) Rename as-is
d) Rename as-is but minus test libs
e) Remove

  1. Shall we include alleycats into the cats repo as submodule? detailed discussion in Make Alleycats a submodule of Cats? #472

Options are:
a) Keep as-is, i.e. separate repo
b) move in as cats submodule. It will keep using a separate top alleycats namespace and will not be included in the cats bundle shall we decide to keep one. As a submodule, its releases will be part of cats release, but unlike cats-core, it is allowed to have binary breaking changes between patch versions for alley-cats, at least for now, since it's API hasn't reached the stable status yet.

  1. Shall we publish cats-testkit? discussion in Publish cats-tests #1656

a) Create a new module called cats-testkit that includes the following utils from cats-tests: Helpers,
CatsSuite and CatsEquality
Note that these classes are not required for users to write cats style tests - cats-laws/discipline is the one that is required. cats-testkit will depend on cats-laws
b) keep as-is
c) simply publish cats-tests ( but not included in the cats bundle shall we have one. )

We've done extensive discussion around these for quite a while. So I propose we are ready to collect votes and see if we can reach consensus.

@kailuowang kailuowang added this to the 1.0.0-MF milestone May 18, 2017
@kailuowang
Copy link
Contributor Author

kailuowang commented May 19, 2017

My vote
1, e
2.b changed to a, I don't see how alleycats is different from cats-mtl or cats-effects
3. a or b

@mpilquist
Copy link
Member

  1. e
  2. a
  3. b

@ghost
Copy link

ghost commented May 19, 2017

My final vote
1, e
2. b
3. b (if we want common test-kits, move them to catalysts)

@djspiewak
Copy link
Member

Only strong opinions are on 2 and 3. On 2, I strongly oppose moving alleycats into the cats repo. Polyrepo is significantly easier to manage here, and it ensures that the versioning is kept independent. Having things like alleycats, dogs, cats-mtl and cats-effect in repos that are separate from cats-core is a major win relative to the way that scalaz is setup, since scalaz's versioning is fundamentally tied together, meaning that changes which are non-breaking for core still have to increment the core breaking version, which in turn cascades through the entire ecosystem.

Regarding 3, option c seems fine, but I'm ok with any which publishes the test infrastructure.

@edmundnoble
Copy link
Contributor

  1. e
  2. a
  3. c please give me cats-tests.

@milessabin
Copy link
Member

  1. e
  2. b
  3. a or b

@kailuowang
Copy link
Contributor Author

kailuowang commented Jul 6, 2017

Results (if a vote for (a or b), I count both)

  1. e (unanimous)
  2. a 4, b 2
  3. a 3, b 4, c 2

I think for 1.0.0-MF, we just do

  1. e remove cats bundle,
  2. a leave alleycats out of cats repo and
  3. a release a test-kit, b got the most vote but I think a will make both a and c voters happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants