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

Light reorganisation of the README #10367

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add information about support window for releases
  • Loading branch information
Kleidukos committed Sep 17, 2024
commit 276eea64efcaef55392740cab77639709118e7b9
6 changes: 6 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,12 @@ This Cabal Git repository contains the following main packages:
The canonical upstream repository is located at
https://github.com/haskell/cabal.

## Support window for releases
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be great to add the GHC support window info somewhere here too. Because that's what I thought about first time I saw this heading.


| Latest release | 3.14 |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From looking at the rendered version, the first line is treated as a header, which looks a little weird.

Copy link
Collaborator

@geekosaur geekosaur Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would make more sense if it actually stated the support windows and the difference between them. I'd suggest some text, but I only have a vague idea of our actual support windows aside from the comments in validate.yml which I've seen too many times 😀 .

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, also this raises a fairly big problem with LTS releases in our context: support for newer compilers, which (given the way we handle them) requires major version bumps. Do we need to add an escape hatch somewhere for when someone quite reasonably expects an LTS cabal-install to work with a newer ghc?

|---|---|
| Long-Time Support release | 3.12 |
Copy link
Collaborator

@ulysses4ever ulysses4ever Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said in the past: I'm mildly against using the term LTS without having any concrete definition for it. Here would be a great place for a short definition btw. But I don't know what it should be, from the top of my head.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We intend long-term support (LTS) releases to be stable releases with ongoing support, for use by projects which can't reasonably follow a moving target of Cabal or cabal-install releases. Previously, the GHCup maintainer was lightly maintaining 3.6 as a stable release, but it's unreasonable to expect him to do so for new releases, so we are providing a maintained stable release ourselves. New LTS major releases will happen as needed, but as yet we have not determined when because we don't have a good feel for how often it will be needed. The LTS release will receive major bug fixes but avoid breaking changes, which will require a new LTS series.

An example would be the 3.14 release that's in progress (or just happened?), which is fairly close on the heels of 3.12.1.0. I can well imagine other projects wanting to stick to a stable but maintained release.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good start, I guess, thank you. It feels vague because LTS policies usually have exact time frames.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because it is vague, and states why it is vague ("as yet we have not determined…"). We weren't even sure 3.12 would be an LTS branch at release time.

Copy link
Collaborator

@geekosaur geekosaur Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for timeframes, we need to find out how hard ghc releases will be pushing us along before we know how long-term the long-term support branches need to be in order to be meaningful. The only thing I can say for certain at this point is that something Ubuntu-like won't work either in terms of time or version numbers. As such, maybe it's best to state that our LTS branch is experimental for now.

Kleidukos marked this conversation as resolved.
Show resolved Hide resolved

## Learn how to use `cabal` and get support

`cabal` comes with a thorough [User Manual](https://cabal.readthedocs.io).
Expand Down
Loading