Preparing for another release (0.7.4)

[Aaron Meurer]

I'd like to start working on getting another release out.

At this stage, we need to go through the pull requests and finish any
that need to be done before the release. I've created the milestones
"For 0.7.4" and "Not for 0.7.4" in the GitHub issue tracker. Please
assign any pull request to one of these two (you can do so at the top
of the pull request, in the grey bar under the pull request title).
If you don't have push access, but want to help, just let me know
which pulls should be merged.

Please be very conservative about which pull requests should be merged
for the release. Things that change APIs should be merged. Things that
fix regressions should be merged if the author is willing to work on
them. New features to not need to be merged before the release. Please
do not mark one of your own pull requests for merging unless you are
willing to put in the work to finish it up within the next couple of
weeks.

Beyond this, any help reviewing and fixing up the need-to-merge pull
requests would be appreciated. You can see which pull requests have
been marked as such here:
https://github.com/sympy/sympy/issues?milestone=5&state=open.

Also, it's good to get this going early: if you know of any major
changes that have been made since the last release, please make sure
they are in the release notes
(https://github.com/sympy/sympy/wiki/release-notes-for-0.7.4). If you
know of them but aren't qualified to write up the details, just put a
note there so we don't forget about it and ping the person who made
the changes. Anyone can edit the release notes page on the wiki, and I
encourage you to do so.

Aaron Meurer

[Sergey Kirpichev]

On Monday, November 11, 2013 2:16:15 AM UTC+4, Aaron Meurer wrote:

Also, it's good to get this going early: if you know of any major
changes that have been made since the last release, please make sure
they are in the release notes
(https://github.com/sympy/sympy/wiki/release-notes-for-0.7.4). If you
know of them but aren't qualified to write up the details, just put a
note there so we don't forget about it and ping the person who made
the changes. Anyone can edit the release notes page on the wiki, and I
encourage you to do so.

Would you like to start shipping release-notes with sympy's tarball from this
release (just like scipy/numpy)?  In this case - it's easy to ask contributors to
write about the changes, just in the same pr request.

[Aaron Meurer]

It's easier to do it the way we currently do it because then we can
fix the release notes retroactively.

We would also have to include them in the repo itself to do it right,
I think, and I'm not sure if we want to do that. I think it was
discussed before, and we decided against it (you can probably find it
if you search the mailing list archives).

I personally like it the way it is now because it makes my life easier
as the person who does the release (again, because I don't have to
make sure the release notes are ready to go when I do the actual
release). It also makes it easy for anyone to go in and add the things
they changed, which is also good for me, as I don't have neither the
time nor the expertise to write the whole release notes myself.

But if enough people want it to change that's fine too.

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 post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> For more options, visit https://groups.google.com/groups/opt_out.

[Joachim Durchholz]

Am 11.11.2013 01:18, schrieb Aaron Meurer:
> But if enough people want it to change that's fine too.

I'm +1 on having release notes.

I'm also +1 on making them easy on the release manager.

I'm not sure how to best do that though. To the very least, merging the
updates to the release notes should not create merge conflicts. That's
not just easier on the release manager, but it's also easier on
contributors when merging or rebasing (they'd need to shift attention
from their own work to the release notes on unrelated work, not good).

[Aaron Meurer]

Yes that's a good point. A CHANGES file would have more merge
conflicts than other files. I think this was ultimately the reason we
decided against this.

Aaron Meurer

[Sergey B Kirpichev]

On Sun, Nov 10, 2013 at 05:18:03PM -0700, Aaron Meurer wrote:
> I think it was
> discussed before, and we decided against it (you can probably find it
> if you search the mailing list archives).

No, AFAIK. At least, I can't guess correct keywords for
nonempty search...

Anyway, there is already two suggestions. First, to provide
release notes with the sympy's tarball. Second, to include them
in the sympy's repo.