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.

Ondrej

-- 
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.

Reply via email to