SymPy 1.10rc1 released

[Oscar Benjamin]

Hi all,

I've just released the release candidate SymPy 1.10rc1. If no issues
are reported then this will be released as SymPy 1.10 in around 1
week's time. Please test this out with your code and downstream
libraries because it's best if any new bugs can be fixed before the
final release of 1.10.

The release notes are here:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10

Some work is needed to tidy up the release notes. Please everyone who
has contributed anything recently check through to see if your release
notes look reasonable. Note that anyone can edit the release notes in
the wiki. If anyone has any questions about any of the release notes
now then feel free to reply here and I'll take a look.

You can install 1.10rc1 for testing with:

$ pip install --pre --update sympy

Alternatively you can use the release files from here:

https://github.com/sympy/sympy/releases/tag/sympy-1.10rc1

The following people contributed at least one patch to this release (names are
given in alphabetical order by last name). A total of 68 people
contributed to this release. People with a * by their names contributed a
patch for the first time for this release; 33 people contributed
for the first time for this release.

Thanks to everyone who contributed to this release!

- Wang Ran (汪然)*
- Advait*
- AkuBrain*
- alijosephine*
- anutosh491*
- Leo Battle*
- Oscar Benjamin
- Anurag Bhat*
- Ayush Bisht
- Remco de Boer
- Francesco Bonazzi
- Zach Carmichael
- Kaustubh Chaudhari
- James Cotton
- Björn Dahlgren
- Nikhil Date*
- Risiraj Dey*
- Travis Ens*
- Isuru Fernando
- Tom Fryers*
- Matthias Geier
- Naman Gera
- Pieter Gijsbers*
- Oscar Gustafsson
- Sayandip Halder
- S. Hanko*
- Jerry James
- Kuldeep Borkar Jr*
- Evgenia Karunus*
- Steve Kieffer*
- Andreas Klöckner
- Matthias Köppe
- Ayush Kumar
- lastcodestanding*
- S.Y. Lee
- Andrey Lekar*
- Alex Lindsay
- Qijia Liu
- Hampus Malmberg*
- Anibal M. Medina-Mardones*
- Aaron Meurer
- mohajain*
- Abbas Mohammed*
- Jeremy Monat*
- Jason Moore
- Sidharth Mundhra
- naelsondouglas*
- Joannah Nanjekye
- Rikard Nordgren
- Chris du Plessis
- Mamidi Ratna Praneeth
- rathmann
- Hanspeter Schmid
- scimax*
- shubhayu09*
- Sudeep Sidhu
- Gagandeep Singh
- Gurpartap Singh*
- Chris Smith
- Paul Spiering*
- Aaron Stiff
- Kalevi Suominen
- Dennis Sweeney*
- Diane Tchuindjo*
- Aman Thakur*
- Eric Wieser
- Zouhair*

(Note: if your name is not correctly recorded here or you would like a
different name to be recorded in the AUTHORS file then please let me
know.)

The SHA-256 hashes for the release files are:

2cd08cad10a974dbef21dfacbb6a6904c5872e07ef11fe00abf5abba98ab9cec
sympy-1.10rc1.tar.gz
ac5b4122f25cbf22a676a1ef81ca814d6055a77d37bedb38b313d66fca0b4048
sympy-1.10rc1-py3-none-any.whl
d104cfcf6ab54c6d7e2dab4b23e58ecc4a278624020bade1828dd3f4e86d74a9
sympy-docs-html-1.10rc1.zip
9ce4bfd9b41cf9048debd46898f39618ef370eee52adf79ed78317431f5fda66
sympy-docs-pdf-1.10rc1.pdf(39venv)


Oscar

[Aaron Meurer]

On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:

Hi all,

I've just released the release candidate SymPy 1.10rc1. If no issues
are reported then this will be released as SymPy 1.10 in around 1
week's time. Please test this out with your code and downstream
libraries because it's best if any new bugs can be fixed before the
final release of 1.10.

The release notes are here:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10 

Some work is needed to tidy up the release notes. Please everyone who
has contributed anything recently check through to see if your release
notes look reasonable. Note that anyone can edit the release notes in
the wiki. If anyone has any questions about any of the release notes
now then feel free to reply here and I'll take a look.

I added a couple of documentation things to the highlights.

With the deprecations now in the docs, it's easy to add the new deprecations by looking at https://docs.sympy.org/dev/explanation/active-deprecations.html#version-1-10, and starting with 1.11, it will also be easy to note which items were removed from that page to notate which deprecated things were removed.

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQnX5-6YBgOc5G4FzYu97%2BFcCM2rU%2BGOL4g2jMzcQL0OQ%40mail.gmail.com.

[Oscar Benjamin]

On Fri, 18 Feb 2022 at 20:58, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>>
>> Hi all,
>>
>> I've just released the release candidate SymPy 1.10rc1. If no issues
>> are reported then this will be released as SymPy 1.10 in around 1
>> week's time. Please test this out with your code and downstream
>> libraries because it's best if any new bugs can be fixed before the
>> final release of 1.10.
>>
>> The release notes are here:
>> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10
>>
>>
>>
>> Some work is needed to tidy up the release notes. Please everyone who
>> has contributed anything recently check through to see if your release
>> notes look reasonable. Note that anyone can edit the release notes in
>> the wiki. If anyone has any questions about any of the release notes
>> now then feel free to reply here and I'll take a look.
>
>
> I added a couple of documentation things to the highlights.

Yes, I should have said that there have been some significant changes
to the docs. This is the 1.9 docs:

https://docs.sympy.org/latest/index.html

This is how the 1.10 docs will look:

https://docs.sympy.org/dev/index.html

There is a lot of work going on around the docs right now so I expect
that the 1.11 docs will be more noticeably different again.

> With the deprecations now in the docs, it's easy to add the new deprecations by looking at https://docs.sympy.org/dev/explanation/active-deprecations.html#version-1-10, and starting with 1.11, it will also be easy to note which items were removed from that page to notate which deprecated things were removed.

Yes, that is an improvement.

Another thing that has changed between 1.9 and 1.10 is the way that
the AUTHORS file is updated which streamlines the release process a
bit. There's one other thing that I'd like to do which is to move the
release notes into the codebase itself rather than the wiki. Then we
could be quite close to a fully automated release process but it would
mean further disruption to the PR workflow.

I have hit a small snag with the 1.10rc1 release which is that after
installing it and running the tests on my computer I now see that
sympy/external/tests/test_pythonmpq.py fails when gmpy2 is installed.
I guess those particular tests are not run in the optional
dependencies job in CI...

--
Oscar

[Aaron Meurer]

On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:

On Fri, 18 Feb 2022 at 20:58, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>>
>> Hi all,
>>
>> I've just released the release candidate SymPy 1.10rc1. If no issues
>> are reported then this will be released as SymPy 1.10 in around 1
>> week's time. Please test this out with your code and downstream
>> libraries because it's best if any new bugs can be fixed before the
>> final release of 1.10.
>>
>> The release notes are here:
>> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10

By the way, a minor note, I had to update the supported Python versions in the header for the 1.10 and 1.11 release notes pages. Whatever process you are using to create the new pages is based on an old version of the release notes.

I get several other failures as well, as noted at https://github.com/sympy/sympy/issues/23061 (I didn't double check if these are all relevant for the 1.10 branch, but I'm guessing they are).

Aaron Meurer

 

--

Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRe%2BpOFji5UWKiL0cO4wUhT0quJFvUCB6kfzyvHnqP97A%40mail.gmail.com.

[Oscar Benjamin]

On Fri, 18 Feb 2022 at 22:30, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>>
>> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer <asme...@gmail.com> wrote:
>> >
>> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I've just released the release candidate SymPy 1.10rc1. If no issues
>> >> are reported then this will be released as SymPy 1.10 in around 1
>> >> week's time. Please test this out with your code and downstream
>> >> libraries because it's best if any new bugs can be fixed before the
>> >> final release of 1.10.
>> >>
>> >> The release notes are here:
>> >> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10
>
> By the way, a minor note, I had to update the supported Python versions in the header for the 1.10 and 1.11 release notes pages. Whatever process you are using to create the new pages is based on an old version of the release notes.

The process is just copying the contents of the old page to the new one :)

That's why I'd rather have the release notes in the repo itself. Much
easier to automate things there and it means that these updates can
happen at the same time that support for new/old versions of Python is
added/removed.

--
Oscar

[Aaron Meurer]

How would you envision the release notes process looking with the notes living in the repo itself?

Aaron Meurer

 

--
Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTOFfAYet3t_tAGDLopf_kah303k2ZPKkK8wnZwO2uQNQ%40mail.gmail.com.

[Oscar Benjamin]

On Sat, 19 Feb 2022 at 01:28, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>>
>> On Fri, 18 Feb 2022 at 22:30, Aaron Meurer <asme...@gmail.com> wrote:
>> >
>> > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>> >>
>> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer <asme...@gmail.com> wrote:
>> >> >
>> >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I've just released the release candidate SymPy 1.10rc1. If no issues
>> >> >> are reported then this will be released as SymPy 1.10 in around 1
>> >> >> week's time. Please test this out with your code and downstream
>> >> >> libraries because it's best if any new bugs can be fixed before the
>> >> >> final release of 1.10.
>> >> >>
>> >> >> The release notes are here:
>> >> >> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10
>> >
>> > By the way, a minor note, I had to update the supported Python versions in the header for the 1.10 and 1.11 release notes pages. Whatever process you are using to create the new pages is based on an old version of the release notes.
>>
>> The process is just copying the contents of the old page to the new one :)
>>
>> That's why I'd rather have the release notes in the repo itself. Much
>> easier to automate things there and it means that these updates can
>> happen at the same time that support for new/old versions of Python is
>> added/removed.
>
> How would you envision the release notes process looking with the notes living in the repo itself?

Currently the release note is made as an edit to the OP of a PR which
is not intuitive and doesn't match the workflow for everything else
where all changes are in the diff. I would like a workflow where the
release note is part of the diff and is clearly visible to the
reviewer who looks at the diff.

There would essentially be something like a release-notes-1.10.md file
for each release but contributors would not edit the file directly.
Instead they add a file somewhere called something like news-12345.md
where 12345 is the PR number. Then at release time all of those files
are compiled into the release-notes-1.10.md file.

The important change from a contributors perspective is that the
release note is added in a file in the diff rather than in the OP of
the PR. From a reviewers perspective the difference is that the
release note should be reviewed as part of the diff rather than
separately (personally I would find it easier to remember to review it
that way).

There would still be a need to have a way to say "no release note"
which should be required explicitly because otherwise most
contributors won't write release notes at all.

--
Oscar

[Aaron Meurer]

I guess I'd like to hear from contributors what they feel about the current way with the PR description + the bot vs. this proposed way. I've contributed to projects that use a system like this, and the SymPy system feels a lot easier to use. You just write the note in the PR description, which is where you should already be writing a summary of what changed. 

I agree the reviewing aspect of our current system should be improved. A lot of people just don't review the release notes at all, and people use "NO ENTRY" more often than they should and no one calls them out on it, even when the change is significant. I'm not sure if that would change with your proposed system. It seems to me that we just need for reviewers to explicitly make this something that they care about when reviewing. The current system is also designed so that a reviewer can add a note themself if they want to (I do this sometimes, but I don't know if anyone else ever does). 

Having the notes in the docs would indeed probably be better. The main downside is you have to do a PR to make any kind of edit.  However, I think it might be possible to do this even with the current system, e.g., by copying them from the wiki at release time, or by making the bot push to the repo instead of the wiki. We can include Markdown documents in the docs now with MyST so that part of it isn't an issue.

Aaron Meurer

 

--
Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQZbur5E7gUDoMqk9mfAbQAE%2Btj38jNSJq6PFahNzhkHQ%40mail.gmail.com.

[Jason Moore]

HI,

I really like the bot and it forces you to at least think about the release notes (even if all you do is write NO ENTRY). Yes, our review culture should be that we don't let NO ENTRY through as much, but that is a culture change. The bot could say, "are you really really sure this only needs a no entry??"

I also think the release notes should be part of the repo, part of the docs, and packaged in the released source tarball.

Having the best of both worlds would be nice. I think scipy or some of the other big python projects do things as Oscar suggests, have a single file per PR that is merged together.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KnTq5D0qqANY3yQYOxGJcm%3Dxun7zx3DTK3oG8GByVcWA%40mail.gmail.com.

[Oscar Benjamin]

On Tue, 22 Feb 2022 at 04:43, Jason Moore <moore...@gmail.com> wrote:
>
> HI,
>
> I really like the bot and it forces you to at least think about the release notes (even if all you do is write NO ENTRY). Yes, our review culture should be that we don't let NO ENTRY through as much, but that is a culture change. The bot could say, "are you really really sure this only needs a no entry??"

When exactly would the bot say that?

The problem with the bot is that it hassles you when you first open
the PR so then you either add NO ENTRY or you add a quick release
note. That only happens at the beginning of the PR lifetime though and
then the PR can evolve significantly afterwards. It might be that at
the time you write the release note you don't yet know what the final
result of the PR will be or some of its effects are not fully
understood. It might be that you start with one approach and then
after review end up with something very different. I know at the end
that I don't click merge without going through the diff but the
release note isn't in the diff so it's a separate step that needs to
be checked. So maybe when you start a PR you add NO ENTRY just to shut
the bot up or maybe you add a release note but it isn't very good
because you're not ready to write a proper note at the time the bot
hassles you.

To me the problem is not so much that some contributors overuse NO
ENTRY but rather that sometimes the notes are uninformative and don't
convey any useful information. By the time it comes round to release
the idea of going through all of them and trying to make sense of them
and improve them is just too much.

> I also think the release notes should be part of the repo, part of the docs, and packaged in the released source tarball.

One thing I like about doing it this way is that then before a release
you can open a PR to do the step of combining all of the release
notes. Then lots of people can review and comment on the notes and
make changes. Authors can be tagged and asked to clarify what they
really mean by their release note. That means we have a second stage
of release note review that focuses only on the notes themselves and
that can also look at the collection of all notes together.

> Having the best of both worlds would be nice. I think scipy or some of the other big python projects do things as Oscar suggests, have a single file per PR that is merged together.

In general I would prefer to have everything in the repo and I think
that means that the release notes have to be in the PR somehow. The
single file approach is mainly just to avoid merge conflicts.

--
Oscar

[Aaron Meurer]

On Tue, Feb 22, 2022 at 6:47 AM Oscar Benjamin <oscar.j....@gmail.com> wrote:

On Tue, 22 Feb 2022 at 04:43, Jason Moore <moore...@gmail.com> wrote:
>
> HI,
>
> I really like the bot and it forces you to at least think about the release notes (even if all you do is write NO ENTRY). Yes, our review culture should be that we don't let NO ENTRY through as much, but that is a culture change. The bot could say, "are you really really sure this only needs a no entry??"

When exactly would the bot say that?

The problem with the bot is that it hassles you when you first open
the PR so then you either add NO ENTRY or you add a quick release
note. That only happens at the beginning of the PR lifetime though and
then the PR can evolve significantly afterwards. It might be that at
the time you write the release note you don't yet know what the final
result of the PR will be or some of its effects are not fully
understood. It might be that you start with one approach and then
after review end up with something very different. I know at the end
that I don't click merge without going through the diff but the
release note isn't in the diff so it's a separate step that needs to
be checked. So maybe when you start a PR you add NO ENTRY just to shut
the bot up or maybe you add a release note but it isn't very good
because you're not ready to write a proper note at the time the bot
hassles you.

Ideally, when this happens you would leave the release notes empty. That way you remember to fill them in before you merge, because the release notes status will be failing. 

I think you're right that a lot of people do this, though. Would it help to have a separate thing you could write like "TODO" which would make the bot give a pending status? We could also make the bot skip draft PRs.

Otherwise, I'm not sure what we can do to make sure people look at the notes at merge time. Maybe require some sort of affirmative review of the notes from the merger?

  

To me the problem is not so much that some contributors overuse NO
ENTRY but rather that sometimes the notes are uninformative and don't
convey any useful information.

This happens too, but I've definitely seen people overuse NO ENTRY as well. To the point that I've considered removing it entirely, and just living with the occasional useless "fix a typo" in the release notes. 

If you're only looking at the release notes document you won't see the NO ENTRYs. Maybe we can make a script that shows every NO ENTRY PR that was part of a release.

 

By the time it comes round to release
the idea of going through all of them and trying to make sense of them
and improve them is just too much.

This is definitely the problem that the bot was intended to solve (having to worry about the release notes at release time). Again, the idea was that reviewers would make sure the release notes look good before merging. If they aren't doing that, we need to figure out how to change that. 

> I also think the release notes should be part of the repo, part of the docs, and packaged in the released source tarball.

One thing I like about doing it this way is that then before a release
you can open a PR to do the step of combining all of the release
notes. Then lots of people can review and comment on the notes and
make changes. Authors can be tagged and asked to clarify what they
really mean by their release note. That means we have a second stage
of release note review that focuses only on the notes themselves and
that can also look at the collection of all notes together.

> Having the best of both worlds would be nice. I think scipy or some of the other big python projects do things as Oscar suggests, have a single file per PR that is merged together.

In general I would prefer to have everything in the repo and I think
that means that the release notes have to be in the PR somehow. The
single file approach is mainly just to avoid merge conflicts.

Just to be clear, I think it is technically possible to keep the notes on the PR entry, and even on the wiki between releases, if that ends up being easier. We can copy the notes from the wiki into the docs at release time. Or we can make the bot post the notes into the repo instead of the wiki. It would also be possible to have the author write the notes in a file instead of the PR description, but continue to use the bot to check things. Or we could remove the bot and do the check on CI. All would have the same end result (the notes in the docs).

So we should figure out which process is most convenient for contributors and for reviewers and aim for that.

Aaron Meurer

--
Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxSVQfXTL9x%2BBYnCRtcxZVhq8sCYH_ojKNWfQhovm0zBUg%40mail.gmail.com.

[Chris Smith]

Could we require that NO ENTRY be followed by a reason that no entry is required? 

Can an open todo list block merge but not block running tests?

/c

[Aaron Meurer]

On Wed, Feb 23, 2022 at 9:24 AM Chris Smith <smi...@gmail.com> wrote:

Could we require that NO ENTRY be followed by a reason that no entry is required? 

Can an open todo list block merge but not block running tests?

Both of these are technically possible. The bot can be programmed to do basically anything we want. For the tests, the default behavior is for one test run to not block all the others. The code quality tests only do this because they are configured to.

Aaron Meurer

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/2770d836-d7cf-40c2-b543-2f44231feeean%40googlegroups.com.