Hi, On Mon, Oct 8, 2012 at 9:42 PM, Ondřej Čertík <[email protected]> wrote: > On Mon, Oct 8, 2012 at 11:58 AM, Aaron Meurer <[email protected]> wrote: >> On Mon, Oct 8, 2012 at 12:25 PM, Ondřej Čertík <[email protected]> >> wrote: >>> On Sun, Oct 7, 2012 at 8:53 PM, Aaron Meurer <[email protected]> wrote: >>> [...] >>>> - We should release *at least* once a month. I think that if the >>>> process is automated enough, that this will be very possible (as >>>> opposed to the current situation, where the release branch lasts >>>> longer than a month). In times of high activity, we can release more >>>> often than that (e.g., after a big pull request is merged, we can >>>> release). >>> >>> We should definitely automate it. I've had great experience with Vagrant, >>> here are my scripts to automate the NumPy release: >>> >>> https://github.com/certik/numpy-vendor >>> >>> That among linux tgz even builds a binary for Windows. The advantage >>> of Vagrant is that anyone can easily run it, both Mac or Linux and >>> the environment is 100% the same. (Travis CI also uses Vagrant btw.) >>> >>> Aaron, are you able to run Vagrant on your Mac? Let me know if you >>> are in favor of that, and I can write the initial release script using >>> Vagrant, >>> and then we keep improving it (all of us). >> >> It seems to work (at least I am able to install it). Is there a simple >> way that I can test that it really works? > > Yes --- follow the instructions: > > https://github.com/certik/numpy-vendor#how-to-use > > it it starts doing something, then it works. It takes a few hours to > actually build everything in Wine inside it, so you don't have to wait, > just kill it with ctrl-C. > > You will need to have Fabric installed (https://github.com/fabric/fabric). > > That is the tool, that allows automatic manipulation of remote servers, > in this case Vagrant VM. Later, we can extend our scripts to do some stuff > on our Linode server or some other servers. > >> >>> >>> >>> ------------- >>> >>> Yes, releasing each week, or each month would be great. >>> >>> I think we are too worried of each release to be "perfect". I wouldn't worry >>> about #1561. I think we can improve the notebook in the next release. >> >> I just noticed that the notebooks are not even included in the tarball >> by default anyway. So I think I will do this. >> >> And anyway, I really think we should have *all* examples be notebooks, >> and we should be doctesting them, etc. >> >> So I'll just merge Sean's IPython extension branch (assuming it >> works), and make a release candidate. I hopefully will do all that >> this evening. >> >>> I think it's more important to get the main code base released and make >>> sure that all tests work on all platforms. I think that's the only issue and >>> I think we are pretty good at that. >> >> It's not the only issue, because as I mentioned, for example, there >> are a dozen sites to update after the release, and that takes a bunch >> of time too. And there's always the release notes (which actually, I > > I can help with the sites. But I think we don't need to update them. > I would just push in the git tag, put tarballs at google code and update pypi. > This can be done by hand.
I've got windows machines set up as buildbots and am hand-triggering bdist builds on a windows xp and windows 7 machine which upload to a web-accessible directory. That could be automated by watching for a release-like git tag I suppose. Of course y'all would be welcome to use these, Cheers, Matthew -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
