-
Notifications
You must be signed in to change notification settings - Fork 696
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
Cabal 2.0 release planning #3576
Comments
What's the timeline expected on this? Such a major version change would perhaps be a good moment to replace |
Well, we'd want to hook this up with GHC 8.2. However note that s/new-build/build/ is a cabal-install change, and so the setup upper bounds is not applicable. cabal-install can break its outwards interface whenever it wants to distinct from the library. |
Yeah, I don't think nix-local-build will be completely ready for prime time in time for the next release. I plan to cut the next release in October/November, so most likely it won't be synced with GHC 8.2 (but the next release after that will). |
Will there be a Cabal 1.26 release? In other words, should we avoid pull-request-ing branches that are intended for Cabal 2.0? Is there a deprecation procedure for things we'd like to remove from Cabal 2.0? |
I'll defer to @23Skidoo on the Cabal 1.26, but given how early convenience libraries were merged into master this cycle, it probably makes more sense to backport useful fixes to 1.24. (As in, master already has a number of BC incompatibilities that are best put into 2.0) So I think PR'ing Cabal 2.0 branches should be OK. I wrote deprecation/BC guidelines in #3573 but amendments welcome. |
I left a suggestion on the deprecation guidelines, but I still have some question about Cabal 2.0 in particular. I'm thinking of the hooks interface here. It would be very convenient to clean that up for Cabal 2.0; given that we will need an upper bound on Cabal for old setup scripts anyway, can we break the hooks interface? |
I am open to fixing the hooks interface, but only if it's very clear what specific problems with the existing hooks interface we are fixing, and how the new design addresses them. I don't have a good idea what an improved hooks interface looks like. And we'd need docs for how to migrate to the new interface, or a shim, etc. |
My proposal was to call the next release 2.0, i.e. release 2.0 instead of 1.26. Since we seem to agree that this is the way to go, I'll rename the milestone to avoid confusion. |
I was expecting we'd bump to 2.0 to mark the nix-local-build transition, since that's gonna be a very visible and disruptive UI change (as well as some subtle semantic changes regarding the meaning of .cabal files). Can we then use a bump to 3.0 instead to advertise making new-build the new default, even if that means that we'll have a quick succession of 1.x -> 2.x -> 3.x versions? |
Sure. |
Yes! I've been suggesting the same. And yes, to clarify this is the Cabal library API. Yes I'd suggest the terrible hooks API as something we should break. There's a bunch of other TODOs/FIXMEs in the code that are there because we could not yet break the Setup.hs API. |
OK, fine by me. |
Also ought to remove overall |
This, is super drastic, but what if we removed custom setup until we found a better design (IMO additional shake rules or something else declarative)? That could maybe help avoid 2->3->>? major version churn as these things get worked out. |
The downside of dropping Custom script is that any packages which use Custom scripts today (and there are multitudes) will be forced to use an old version of the Cabal library and will not get any future bugfixes. The payoff doesn't seem so good: it is true that now you can change the Cabal API without worrying about BC, but if you are going to reimplement Cabal with Shake you are probably going to end up with a complete rewrite, so no point in reusing the old code. On September 20, 2016 9:13:09 AM GMT+09:00, John Ericson [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
That a convincing counter argument :). I'd still like to get people off custom installs and rethink the relationship between Cabal and cabal-install (and stack)—Cabal's remaining users. But more version bumps is a small price to pay and that can still be schieved more slowly. |
Short term, the best way to get people off Custom setups is to (1) add features to Cabal build system which subsume the use cases people use for Custom (see also #3788), and (2) make it possible to version-gate a Custom setup so that if the Cabal library is sufficiently new you don't do anything non-standard (maybe a pile of ifdefs is enough, though you don't get per-component builds that way.) |
What is the status here? GHC 8.2 is quickly approaching; is the |
My read on the situation is that the Cabal tree is releasable today, we have not done any "break the tree pending some future change" changes. |
Yep, I think it's time to create the 2.0 branch. |
Great news. It would be great if someone could ping me when this happens. |
@bgamari Sure, I will. How quickly is GHC 8.2 approaching? Are the dates in https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1 accurate? |
@23Skidoo yes, ideally we would have a final release tag for |
How close are we to cutting a 2.0 branch at this point? |
@bgamari I think I'll do it during the weekend. |
@23Skidoo are we getting close yet? The 8.2 branch is going to be cut any second now. |
The 2.0 branch has been cut. Also FYI, I'd quite like this patchset #4337 to make it in the 2.0 branch. |
What is the plan regarding cutting a 2.0.0 release? |
@bgamari In principle can be done right now, but there are some patches that I want to cherry-pick first. When do you need it? |
I'd still really like to get the last bit of work for local |
@23Skidoo, I would ideally like to have the submodules stabilized for the next RC, which I would like to cut at some point this week. |
@bgamari can we make it a more concrete deadline, say "on sunday" or something like that? I keep finding bugs in Cabal... and I still have to finalise a few other ghc submodules too... :-) |
Herbert Valerio Riedel <[email protected]> writes:
@bgamari can we make it a more concrete deadline, say "on sunday" or something like that? I keep finding bugs in Cabal... and I still have to finalise a few other ghc submodules too... :-)
Sure, "On Sunday" sounds fine to me.
|
OK, it'll be Sunday then. |
How are things looking here? |
For the future: I'd like to have a feature (and API) freeze at about the same time as GHC releaase is frozen. I won't fix Sorry for causing inconvenience, but my time is limited, and making compat package for a moving target just won't work. Should have added Kmett's custom setup script as a test case; didn't think we will break API that much. I'll add it after there is a tag. |
ping @23Skidoo |
@23Skidoo Can we have the tag + release tomorrow (on Friday) with or without an update. The "deadline" (Sunday) passed already, the delays in releases/freezes accumulate. |
OK, sure. |
Thanks @23Skidoo! Assuming this gets done I think we should have an rc2 by the weekend. |
As I was made aware of by @ezyang, cabal release are infrequent. I'd like to see if there is support for adding #4480 (Adding cabal doctest) to the release. I know that @phadej is rather against this. I'd like to still layout my reasoning: My reason for implementing Assuming this makes it into the release, |
I'll chime in that I would also look positively upon this making it into 8.2. It's a simple matter to look at the commit set and see that it is very low risk: even if the implementation of doctest itself is buggy (it probably is; not enough testing yet ;) it is highly unlikely to affect other functionality, or Cabal API users (the only risk is the extra hooks, but we already encourage people to use emptyUserHooks to be stable over additional hooks.) |
Merged doctest patches into the 2.0 branch. The feature seems to lack documentation, which is probably for the better for now. |
Merged everything I wanted into 2.0, all that remains now is to wait for CI to become green and create a tag. |
Cabal-v2.0.0.0 tag has been created. /cc @bgamari |
If they use my PPA with the |
@hvr I've been really bad with getting ahead with |
(This may be a tangent:) What are we generally aiming for wrt. release timing? I understand that there's a good reason to synchronize Cabal releases with GHC, but is there anything (technically) preventing more frequent releases of "cabal-install"?[1] The reason I ask is that several projects have had great success with frequent (e.g. tri-monthly) time-based releases so that if a feature misses its release target, it'll just get pushed to the next (predictable) release date rather than being pushed into some uncertain "some day" future release. Does this sound like something which it might be reasonable to adopt for [1] I also understand that there's quite a tight versioning relationship between |
@BardurArantsson are you thinking about major or minor releases of |
GHC 8.2 release got delayed, and cabal-install/Cabal 2.0 got delayed too as a consequence. I think we should release 2.2 ~in the middle of the next GHC release cycle to avoid getting into this situation again. I'd also like us to move to ~six-month release cycles. |
@hvr I really just mean regular, predictable and above all frequent releases. @23Skidoo Is every six months frequent enough? That still leads to a big (disproportionate) disappointment if $MY_PULL_REQUEST doesn't make it in. I think it's worth aiming for 3 months and then trying to automate things enough that 3-month release cycles aren't overwhelming in terms of work for the Release Manager (i.e. you :) ). (Don't get me wrong, I get that there are good reasons for the current situation. What I'm asking is if we could change it.) |
I think three months is a bit too short given the current level of developer activity. |
2.0 is out, I believe this can be closed. |
In #3545 (comment) @23Skidoo suggested that we should cut Cabal 2.0 next release. The primary implication of this is that the default Cabal upper bound for setup dependencies will EXCLUDE this new version: this means backwards incompatible changes can be made without instantly breaking old Custom Setup scripts.
Of course, that doesn't mean we should go breaking backwards compatibility will nilly. This is a tracking ticket for specific incompatibility we plan to introduce in 2.0, and the motivation behind it. Please edit with other instances.
configPrograms
fromProgramConfiguration
toLast' ProgramConfiguration
@hvr (subsequently undone in 0077e2c)PACKAGE_VERSION
macro for currently being compiled package itself @erikdz-
prefixed packages are now reserved @ezyangCopyFlags
has newcopyArgs
field @ezyangregisterPackage
takes ADTMultiInstance
rather thanBool
@ezyangOriginalModule
is now calledModule
@ezyangcomponentPackageRenaming
is now calledcomponentIncludes
@ezyang--assume-deps-up-to-date
flags @ezyang 85a76c9 1d27ac7 2fac2ecSetupBuildInfo
getsdefaultSetupDepends
field @23SkidoohscolourPref
/haddockPref
takes extraHaddockTarget
,haddockForHackagetype changed to
Flag HaddockTarget` @bennofsAllowNewer
generalized intoRelaxDeps
@hvrLocalBuildInfo
refactor @ezyangPlanned work:
The text was updated successfully, but these errors were encountered: