-
Notifications
You must be signed in to change notification settings - Fork 45
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
SPEC 0: Soften explicit drop schedule. #273
Conversation
This does only change the presenting of the drop information: - reduplicate when the same package was released twice in the same quarter. - Remove the day of month. I don't think it helps conveying the flexibility that the spec
The format of You may want to use the |
I think this is a good idea and I'm in support of this change. Something I've been thinking about with respect to the flexibility of this SPEC is the implications of the word "drop". I wonder if we add language saying that "drop" doesn't mean explicitly removing support, but rather not continuing support for that versioning. What do you think? ETA: Whoops. I see that conversation is already happening in #272 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like the cleaner look of your table solution than what we currently have.
2026 – Quarter 4: | ||
|
||
- 01 Oct 2026: drop python 3.12 (initially released on Oct 02, 2023) | ||
#### 2023 - Quarter 4: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that the previous quarter could be kept around for a bit of an overlap.
spec-0000/schedule.md
Outdated
- 01 Oct 2026: drop python 3.12 (initially released on Oct 02, 2023) | ||
#### 2023 - Quarter 4: | ||
|
||
Recommend drop support for: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rendered version could maybe benefit from a tiny bit of different formatting, either leaving more space between this line and the table itself, or making this line with a different typeface (italic should be enough, no need to make it a heading).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, spacing need css change, as prettify reformat the markdown anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about #273 (comment) then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can put the markdown inside of
<!-- prettier-ignore-start -->
and
<!-- prettier-ignore-end -->
to prevent prettier from messing with your formatting.
Feel free to let @alphapapa know if you would like any css updates to the theme. You are also welcome to just make a PR if you prefer.
Co-authored-by: Brigitta Sipőcz <[email protected]>
I've tried reading 1 quarter in the past. |
I quite like what I see under the current preview link, not sure why prettier doesn't like it though. |
Easiest is to run the generated result through prettier and look at the resulting diff. |
Or ask the pre-commit bot to autofix it. |
If it's for a generated file, you'd have to run that each time you produce the file. |
Here is what prettier does. For example, it changes this
to
I would update the script to just generate the table so that prettier is happy. It might be easiest to use something like: |
0326a44
to
cec29bb
Compare
cec29bb
to
2343242
Compare
There is a blank line at the end of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rendering looks good to me so I keep my approval for merging as I don't have strong opinions on how the code archives that
(I have the feeling that the astropy fixed width ascii table writer could recreate something like these in much fewer lines, but don't think it would be worth the effort of rewriting everything)
This does only change the presenting of the drop information:
--
This also regenerate the files