To me the backwards compatibility thing is part of the problem. A lot of the time the release blockers are about cleaning up some API that is new since the previous release. We need to do it so that we aren't forced to break it again in a later release. Or sometimes they are about fixing a major regression. Regressions aren't always noticed right away, though obviously they are noticed a lot faster if we actually release a version with a change.
But I do agree that would could and should automate everything to the point where we could theoretically do it every PR. I don't know that we would actually want to release *that* often, but that's the level of automation we need. We are pretty close as far as automation goes. I think there are still a couple of minor things that are missing. And we would also have to move our release script to run on a CI (which I think is a good idea anyway). Aaron Meurer On Tue, Nov 12, 2019 at 4:46 PM Jason Moore <moorepa...@gmail.com> wrote: > > There are two things that I think are important: > > - don't include backwards incompatible changes in releases without a > deprecation cycle (cycle should be measured in real time, not # cycles) > - don't introduce new features that we aren't confident we want to support as > public API > > If we have strict policy about those two and releasing is automated enough > that it isn't a time burden, could't we theoretically release after ever PR? > > Jason > moorepants.info > +01 530-601-9791 > > > On Tue, Nov 12, 2019 at 3:28 PM Aaron Meurer <asmeu...@gmail.com> wrote: >> >> I've been thinking about how we can release SymPy more often. It's >> apparent that there are two main things that have prevented it from >> happening: >> >> - My limited time to do the release >> - The release blocking issues (the issues on the milestone on GitHub) >> >> The first issue I hope should be solved by getting more people than >> just myself to do the releases. That's why I'm excited that Oscar is >> doing the 1.5 release. >> >> The second issue is harder. I think we need a better policy on what >> issues are allowed to block a release. I've started a discussion at >> https://github.com/sympy/sympy/issues/17885. I encourage everyone to >> give input on it. >> >> Aside from making it clearer which kinds of issues are allowed to >> block a release, does anyone have any suggestions on how we can manage >> release blocking issues more effectively, or generally how we can >> release more often? >> >> 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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAKgW%3D6JEutrC1mzOpS6dHihk6NzTz4uWkhiuHKkEBOUuDqqzdA%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/CAP7f1Ai91j_8%2B1thSTtO8%2BOUfqQMi5dgqY8-v0G-G_cD_J%2B5iQ%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%2BdOOGNmbUYw-apLPDNBxApKbO%3D2Ue2%3D3ZJO5v53yNiqQ%40mail.gmail.com.
