Thanks for the terminology clarification, Gershom. As a general note, adding features or completing hitherto incomplete features on the release branch is something that should be avoided as much as possible. For starters, it is generally more work than doing it before the release branch is cut as things need to be added to master and the release branch, which slowly diverge. Moreover, the main purpose of the release branch is to stabilise the code base and to do so in a timely manner. As an example, if there is a new type system extension, but the error message are still bad, it may be allowed on the release branch with the understanding that the error messages are going to be fixed during the first month or so of the release branch lifecycle (i.e., the bulk of the work is done and tested before the release branch is cut).
This in particular implies that everything merged to the release branch has to have been well tested (the wiki page states, ”[o]nly previously agreed on, stable and tested new functionality is allowed in.”) Implicitly adding new functionality by depending on a moving library dependency, which is out of the quality control of the GHC team, is not something that I would call ”stable and tested functionality". If we depend on the release version of a library on the release branch, we are still free to bump the library version if that is necessary to fix bugs (which may creep up due to GHC testing as you suggest) — I would expect that to be patch level bumps, though. If new library features are not sufficiently stable to move to that less tightly coupled process from T-3, then that feature set simply has to wait for the next GHC release (which by the new schedule will come much more quickly than before). Let me reiterate that the tighter release process is aimed at being able to achieve more frequent and more predictable GHC releases. This again ought to help the library development, too. In other words, we slow down at the right place to move faster overall (an old Kung Fu trick ;) Cheers, Manuel > 20.12.2017, 04:28 Gershom B <gersh...@gmail.com>: > > Good questions. In my below proposal I think I made an error in naming > things. I checked back at the wiki page for the new release calendar > schedule: > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedule > > Based on that, what I was calling "freeze" is really just cutting the > branch. But it isn't intended as a full freeze. That happens 3 months > before release. The "feature freeze" in that calendar only comes with > the first RC, 1 month before release. > > I think that this timing still works with the proposal I have however > -- bundled libs branch when GHC branches (T-3), and cut releases when > GHC cuts the first RC (T-1). For bundled libs, I think we'd want to > treat that branch (T-3) as closer to a feature freeze. > > However, and here I disagree with Manuel, I think there's plenty of > reason to _not_ cut release versions of libs at the time of the T-3 > branch. In particular, due to the coupling, this may cause trouble if > there are cross-cutting changes that need to be implemented for the > sake of GHC working properly over the three month duration of the > alpha. If there's a feature in a library designed to work in > conjunction with a change in GHC, and that change in GHC needs to be > altered in the course of the alpha (which may not be uncommon -- bug > testing can often reveal such things) then it is likely the library > may need to be changed too. I don't see any concrete goal solved in > making this process significantly more difficult. I thought Moritz' > examples in this thread were very revealing with regards to such > possibilities. It is not clear what cost function the stronger > proposal is trying to optimize for. > > If it is that we want a branch that is "always ready to be cut for > release" (why? is such a thing even possible anytime in the > foreseeable future?), one middle ground may be to cut _candidate_ > releases of bundled libs on branch (T-3). > > --Gershom > > > On Tue, Dec 19, 2017 at 10:12 AM, Michael Snoyman <mich...@snoyman.com> wrote: >> Thanks for spelling this out Gershom. Reading it through, here are my >> questions: >> >> 1. What's the definition of "feature freeze"? Does it mean API stability? >> Does it mean not code changes at all except to fix a bug? Are performance >> fixes allowed in that case? >> 2. What's the minimum time between GHC cutting a feature-freeze branch and >> the first release candidate? And the minimum time between first release >> candidate and official release? Obviously, if each of these is 1 week (which >> I can't imagine would be the case), then these libraries could cut a >> feature-freeze branch after the official release, which obviously isn't >> intended. I apologize if these timings are already well established, I'm not >> familiar enough with GHC release cadence to know. >> >> I can't speak to GHC development itself, but from a downstream perspective, >> this sounds like the right direction. >> >> On Mon, Dec 18, 2017 at 9:41 PM, Gershom B <gersh...@gmail.com> wrote: >>> >>> Let me try to formulate a synthetic policy as per Simon's request: >>> >>> Policy: >>> Bundled library maintainers agree to the following: >>> 1) When GHC cuts a feature-freeze branch, they too (if anything has >>> changed) cut a feature-freeze branch within two weeks at the maximum >>> (ideally sooner), to be included in the main GHC freeze branch. If >>> they do not do so, the last released version will be included instead. >>> 2) When GHC releases the first release candidate, maintainers (if >>> anything has changed) release new versions of their packages, to then >>> be depended on directly in the GHC repo. All submodules are then >>> replaced with their proper released versions for GHC release. >>> >>> This policy can be enforced by GHC hq as part of the release process >>> with the exception of a case in which there's coupling so that a new >>> GHC _requires_ a new submodule release, and also the maintainer is not >>> responsive. We'll have to deal with that case directly, likely by just >>> appealing to the libraries committee or something to force a new >>> release :-) >>> >>> Motivation: >>> This should help address multiple issues: 1) holdup of ghc on other >>> releases. 2) lack of synchronization with ghc and other releases. 3) >>> low lead-time for people to adapt to API changes in forthcoming >>> library releases tied to ghc releases. In particular, because Cabal is >>> part of this policy, it should help circumvent the sorts of problems >>> that led to this thread initially. Further, because this only applies >>> to freeze/release branches, it should not slow down >>> rapid-implementation of cross-cutting changes more generally. >>> >>> Cheers, >>> Gershom >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
