search

nickel-org / cookies

Cookie support for nickel applications
3 stars 7 forks source link

feat(*): bump version to 0.2 #4

Closed Ryman closed 8 years ago

Ryman commented 8 years ago
Ryman commented 8 years ago

cc @jolhoeft @cburgdorf @SimonPersson

There was a suggestion on #3 about mirroring the version number between cookies (and other crates I guess) and nickel. As I see it, this has the advantage that people can see at a glance what versions are compatible which could minimize some pain when major versions change.

I think it could be problematic if you want to make a big change to one of the dependencies (e.g. cookies) without changing the situation with respect to nickel. Has anyone seen any precedent of this kind of versioning in the ecosystem? I've seen that the piston project has wildly different version numbers which allows each crate to iterate at its own pace, but I haven't been keeping a close eye on things recently.

Has anyone got any convincing arguments or anecdotal evidence in either direction? (I'm leaning towards independent versioning for now)

jolhoeft commented 8 years ago

I originally suggested syncing the version numbers. However, I think a better approach would be to make cookies an optional dependency of nickel. Then when a new major version of nickel requires a new major version of cookies cargo will manage it automatically.

Ryman commented 8 years ago

I agree that that would be better, it's been on my mind for a while but I've been hesitant on making the changes as I expected hyper-async to land and require reworking anyway. To make it work I think it requires refactoring nickel into nickel-core and nickel(as a facade of reexports) so that cookies can only depend on nickel-core and we don't get circular dependencies when nickel re-exports cookies.

For now I'll publish this as 0.2.