Skip to content

Light reorganisation of the README #10367

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

Kleidukos
Copy link
Member

@Kleidukos Kleidukos commented Sep 17, 2024

No description provided.

README.md Outdated
--------------------------------
## Support window for releases

| 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?

README.md Outdated

| Latest release | 3.14 |
|---|---|
| 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.

README.md Outdated
@@ -31,7 +45,7 @@ Ways to get the `cabal-install` binary
2. _[Download from official website](https://www.haskell.org/cabal/download.html)_:
the `cabal-install` binary download for your platform should contain the `cabal` executable.

#### Preview Releases
### Preview Releases

_Getting unreleased versions of `cabal-install`_: gives you a chance to try out yet-unreleased features.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
_Getting unreleased versions of `cabal-install`_: gives you a chance to try out yet-unreleased features.
Getting unreleased versions of `cabal-install` gives you a chance to try out yet-unreleased features.

The colon and italics don't make sense after turning this from a bullet point to a regular paragraph.

README.md Outdated

Build for hacking and contributing to cabal
-------------------------------------------
## Contributing to cabal
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks, I like this much more than the previous version! Maybe, backtickize cabal?

Suggested change
## Contributing to cabal
## Contributing to `cabal`

@ulysses4ever
Copy link
Collaborator

I just realized that README is still inconsistent w.r.t. cabal vs. cabal-install. It probably should use one of these to mean the tool? And I'm less sure about how to designate Cabal, the project. I'd prefer "Cabal" (no backticks to avoid too much similarity to cabal(-install)) but I think Mikolaj expressed concerns about that in the past (?).

@Kleidukos
Copy link
Member Author

@Mikolaj do you still have concerned about the typographical differences between the Cabal project, and the cabal executable?

@Mikolaj
Copy link
Member

Mikolaj commented Sep 19, 2024

Yes, IIRC, I preferred "cabal" to "Cabal" as the project name, mostly on historic grounds and also because we have "Cabal the library" and also because "the Grep project" sounds silly and cabal is, most visibly, a commandline tool, so it's rather like "grep" than "Firefox".

But I defer to the PR author --- improving the README is much more important than such details.

@ulysses4ever
Copy link
Collaborator

@Kleidukos do you want to revisit it? There are a couple of small issues in markup (see my comments above) but other than it'd be a shame to leave it behind...

@Kleidukos
Copy link
Member Author

Yes I'll get back to it, thanks

@Mikolaj
Copy link
Member

Mikolaj commented Mar 13, 2025

@Kleidukos: pretty ping? :)

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
@Kleidukos Kleidukos requested a review from ulysses4ever March 13, 2025 11:30
@Kleidukos Kleidukos requested a review from Mikolaj March 13, 2025 11:35
@Kleidukos
Copy link
Member Author

@Mikolaj don't be shy now, it's your turn ;-)

Copy link
Collaborator

@ulysses4ever ulysses4ever left a comment

Choose a reason for hiding this comment

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

Thanks for resuming the work on it!

Good readme's are hard. I have a bunch of suggestions that hopefully could move it in the right direction a bit more.

This Cabal Git repository contains the following main packages:
This repository contains the following packages:
Copy link
Collaborator

Choose a reason for hiding this comment

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

The word "main" was making a point that there's more than that and indeed there is. I agree that it's maybe not the most important piece of info but I was surprised when I learned how many packages are hosted in this repo :'-)

Comment on lines +24 to +29
<dl>
<dt>Latest release</dt>
<dd>3.14</dd>
<dt>Long-Term Support release</dt>
<dd>3.12</dd>
</dl>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Another piece of info that has to be maintained every release, sigh... A more effective way to convey latest release is to make sure github releases are keeping up (there aren't usually).

As before, I'm against introducing the term LTS without a definition. I also don't see enough human-power to support yet another concept.

Lastly, this block takes an enourmous amount of space but only gives two numbers, one of which (LTS) is about an under-specified thing that's not necessarily relevant for most people. The other number most people will look up by looking at the releases pane in the github sidebar. I don't think this block pulls its own weight.

Also, why "support window", what's window'y in these two numbers? Does it mean we support all versions between latest and LTS? I hope not. Overall, if this whole block survives (I hope not), the heading should be changed.

Comment on lines +37 to +38
Got questions? Ask in [Haskell Matrix](https://matrix.to/#/#haskell:matrix.org)
(online chat) or [Haskell Discourse](https://discourse.haskell.org).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we advertize issues/discussions here? I personally like to answer Cabal questions but I very partially read Discourse and in Matrix anything can bubble up pretty quickly. I do monitor new issues/discussions here. So, I'd prefer it be mentioned here. Maybe it's personal...

Got questions? Ask in [Haskell Matrix](https://matrix.to/#/#haskell:matrix.org)
(online chat) or [Haskell Discourse](https://discourse.haskell.org).

## Ways to get the `cabal-install` binary
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 cabal in the previous heading and cabal-install here. Can we have it standardized at least inside one document, please?


_Getting unreleased versions of `cabal-install`_: gives you a chance to try out yet-unreleased features.
_Getting unreleased versions of `cabal-install`_ gives you a chance to try out yet-unreleased features.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
_Getting unreleased versions of `cabal-install`_ gives you a chance to try out yet-unreleased features.
Getting _unreleased versions_ of `cabal-install` allows you to try out yet-unreleased features.


Build for hacking and contributing to cabal
-------------------------------------------
## Contributing to `cabal`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same cabal/cabal-install mish-mash in this heading vs. the previous.

Copy link
Member

@Mikolaj Mikolaj left a comment

Choose a reason for hiding this comment

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

Lets wait with this until the comments are resolved and until we confirm that we want to advertise 3.12 to be the LTS.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 10, 2025

Related to this PR: we've decided in todays' devs meeting that cabal LTS is postponed until the idea is rethought and maybe until GHC has regular LTS releases and we can piggy-back or something. So, advertising LTS in the README may be premature.

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 this pull request may close these issues.

5 participants