Skip to content

Add dev guide#686

Open
kirtchev-adacore wants to merge 1 commit intorust-lang:mainfrom
kirtchev-adacore:fls-685-create-fls-dev-guide
Open

Add dev guide#686
kirtchev-adacore wants to merge 1 commit intorust-lang:mainfrom
kirtchev-adacore:fls-685-create-fls-dev-guide

Conversation

@kirtchev-adacore
Copy link
Copy Markdown
Contributor

This PR adds a new appending to the FLS - the dev guide.

Closes: #685

@kirtchev-adacore kirtchev-adacore self-assigned this Mar 25, 2026
@kirtchev-adacore kirtchev-adacore force-pushed the fls-685-create-fls-dev-guide branch from a7d1479 to e2c68d0 Compare March 25, 2026 12:24

.. informational-page::

Developer's Guide
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

maybe we call it "Developer Guide", so as to match what Reference calls its equivalent (but feel free to ignore this since it's so nit)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines +17 to +19
The Changelog is located in ``src/changelog.rst``.
It should be updated using one of the sentence patterns outlined below.
Note that this is not an exhaustive list, and special cases would need to use their own wording.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

to follow the Line length guideline

Suggested change
The Changelog is located in ``src/changelog.rst``.
It should be updated using one of the sentence patterns outlined below.
Note that this is not an exhaustive list, and special cases would need to use their own wording.
The Changelog is located in ``src/changelog.rst``. It should be updated using one of the sentence patterns outlined below. Note that this is not an exhaustive list, and special cases would need to use their own wording.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fixed. I had forgotten about those...

Glossary entries
~~~~~~~~~~~~~~~~

When working with glossary entries, use the following sintence pattern for a single glossary entry::
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
When working with glossary entries, use the following sintence pattern for a single glossary entry::
When working with glossary entries, use the following sentence pattern for a single glossary entry::

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

It should be updated using one of the sentence patterns outlined below.
Note that this is not an exhaustive list, and special cases would need to use their own wording.

Glossary entries
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

not sure we want to document glossary entries since they are informational content (and we are planning to have them be mere duplicates of main content anyways)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I think we should keep this part in for now. Once the glossary generation machinery is in, we will remove this part.


or::

No change: <Reasons> are outside the scope of the FLS
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would instead use a different example here instead of only add a plural version of the previous example. Maybe you can even list a number of other patterns:

  • "No change: this bug was not documented in FLS"
  • "No change: this lifted restriction was not specified in the FLS"
  • "No change: This behavior was not documented in the FLS"

Also, I do wonder if we it's important to have "No change", as the text that follows it should make it clear why the change is not getting documented.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

How about just shrinking this to

No change: <Reason>

?

I can go either way with keeping/removing the No change part. I think we should have a brief discussion about it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

yeah, that works... we can maybe try keep the consistency in reviews, so we don't have too many variations for the same information

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah, let's discuss a bit in the meeting to align.

This PR adds a new appending to the FLS - the dev guide.

Closes: rust-lang#685
@kirtchev-adacore kirtchev-adacore force-pushed the fls-685-create-fls-dev-guide branch from e2c68d0 to ed99280 Compare March 31, 2026 10:10
Copy link
Copy Markdown
Contributor

@PLeVasseur PLeVasseur 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 pulling this together @kirtchev-adacore!

I think it looks good overall.

Let's chat a bit about it in our meeting today.

View changes since this review

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.

Create FLS dev-guide

3 participants