Re: [sympy] SymPy 1.10rc1 released
On Wed, Feb 23, 2022 at 9:24 AM Chris Smith 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 > /c > On Tuesday, February 22, 2022 at 3:38:59 PM UTC-6 Aaron Meurer wrote: > >> On Tue, Feb 22, 2022 at 6:47 AM Oscar Benjamin >> wrote: >> >>> On Tue, 22 Feb 2022 at 04:43, Jason Moore 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
Re: [sympy] SymPy 1.10rc1 released
On Tue, Feb 22, 2022 at 6:47 AM Oscar Benjamin wrote: > On Tue, 22 Feb 2022 at 04:43, Jason Moore 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit >
Re: [sympy] SymPy 1.10rc1 released
On Tue, 22 Feb 2022 at 04:43, Jason Moore 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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxSVQfXTL9x%2BBYnCRtcxZVhq8sCYH_ojKNWfQhovm0zBUg%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
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 On Tue, Feb 22, 2022 at 1:27 AM Aaron Meurer wrote: > > > On Fri, Feb 18, 2022 at 6:49 PM Oscar Benjamin > wrote: > >> On Sat, 19 Feb 2022 at 01:28, Aaron Meurer wrote: >> > >> > On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin < >> oscar.j.benja...@gmail.com> wrote: >> >> >> >> On Fri, 18 Feb 2022 at 22:30, Aaron Meurer wrote: >> >> > >> >> > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin < >> oscar.j.benja...@gmail.com> wrote: >> >> >> >> >> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer >> wrote: >> >> >> > >> >> >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin < >> oscar.j.benja...@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. >> > > 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
Re: [sympy] SymPy 1.10rc1 released
On Fri, Feb 18, 2022 at 6:49 PM Oscar Benjamin wrote: > On Sat, 19 Feb 2022 at 01:28, Aaron Meurer wrote: > > > > On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> > >> On Fri, 18 Feb 2022 at 22:30, Aaron Meurer wrote: > >> > > >> > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> >> > >> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer > wrote: > >> >> > > >> >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin < > oscar.j.benja...@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. > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxQZbur5E7gUDoMqk9mfAbQAE%2Btj38jNSJq6PFahNzhkHQ%40mail.gmail.com > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit
Re: [sympy] SymPy 1.10rc1 released
On Sat, 19 Feb 2022 at 01:28, Aaron Meurer wrote: > > On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin > wrote: >> >> On Fri, 18 Feb 2022 at 22:30, Aaron Meurer wrote: >> > >> > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin >> > wrote: >> >> >> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer wrote: >> >> > >> >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin >> >> > 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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQZbur5E7gUDoMqk9mfAbQAE%2Btj38jNSJq6PFahNzhkHQ%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin wrote: > On Fri, 18 Feb 2022 at 22:30, Aaron Meurer wrote: > > > > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> > >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer wrote: > >> > > >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin < > oscar.j.benja...@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? 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTOFfAYet3t_tAGDLopf_kah303k2ZPKkK8wnZwO2uQNQ%40mail.gmail.com > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LPkq2OghOqaUpthDbZG1ZCxqfmdY%3DBm%2BbsCvyv%2B-g43Q%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
On Fri, 18 Feb 2022 at 22:30, Aaron Meurer wrote: > > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin > wrote: >> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer wrote: >> > >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin >> > 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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTOFfAYet3t_tAGDLopf_kah303k2ZPKkK8wnZwO2uQNQ%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin wrote: > On Fri, 18 Feb 2022 at 20:58, Aaron Meurer wrote: > > > > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin < > oscar.j.benja...@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. > > >> > >> > >> > >> 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... > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxRe%2BpOFji5UWKiL0cO4wUhT0quJFvUCB6kfzyvHnqP97A%40mail.gmail.com > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BBWxE1g062Z4EvMpJib1hFZoY9H%3DAAorgKJGnTOW1D8Q%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
On Fri, 18 Feb 2022 at 20:58, Aaron Meurer wrote: > > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin > 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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRe%2BpOFji5UWKiL0cO4wUhT0quJFvUCB6kfzyvHnqP97A%40mail.gmail.com.
Re: [sympy] SymPy 1.10rc1 released
On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin 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 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 > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxQnX5-6YBgOc5G4FzYu97%2BFcCM2rU%2BGOL4g2jMzcQL0OQ%40mail.gmail.com > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LBE8zesR43ORiYsotpDNFxcx4O88fVUgvKpdS-fUA9yQ%40mail.gmail.com.
