numpy-discussion

[Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Travis O. <oli...@ie...>]

I've created the 1.0b1 release tag in SVN and will be uploading files 
shortly to Sourceforge.

I've also created a 1.0 release branch called ver1.0

The trunk is now version 1.1 of NumPy and should be used for 
new-development only.  I don't expect 1.1 to come out for at least a year.

Bug-fixes and small changes can happen on the 1.0 branch.  These will be 
merged periodically to 1.1 or vice-versa.  But, the 1.0 branch will be 
used for releases for the next year.

AFAIK, this is similar to Python's release plan.

I'm also going to be out of town for a few days and may not be able to 
check my email so you can ask questions, but I may not answer them for 
several days :-)

Thanks to all you who helped with this release with bug reports and 
patches:

Robert Kern
David Cooke
Pearu Peterson
Alexander Belopolsky (Sasha)
Albert Strasheim
Stefan van der Walt
Tim Hochberg
Christopher Hanley
Perry Greenfield
Todd Miller
David Huard
Nils Wagner

Thank you...

I hope you all have a great weekend :-)  Let's continue to make the beta 
release period productive by improving documentation and getting 
code-coverage tests and tracking down any bugs.

Best regards,


-Travis

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Damien M. <dj...@mi...>]

On Fri, 21 Jul 2006, Travis Oliphant wrote:

> 
> I've created the 1.0b1 release tag in SVN and will be uploading files 
> shortly to Sourceforge.

FYI numpy-1.0b1 builds fine and passes all its regression tests
on OpenBSD -current.

-d

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Rudolph v. d. M. <ru...@sk...>]

I just built numpy-1.0b1 on Mac OS X (10.4.7) using gcc 4.0 and it
fails 2 of the regression tests. Here is the output:

===================
ActivePython 2.4.3 Build 11 (ActiveState Software Inc.) based on
Python 2.4.3 (#1, Apr  3 2006, 18:07:18)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.test()
  Found 5 tests for numpy.distutils.misc_util
  Found 3 tests for numpy.lib.getlimits
  Found 30 tests for numpy.core.numerictypes
  Found 32 tests for numpy.linalg
  Found 13 tests for numpy.core.umath
  Found 4 tests for numpy.core.scalarmath
  Found 8 tests for numpy.lib.arraysetops
  Found 42 tests for numpy.lib.type_check
  Found 147 tests for numpy.core.multiarray
  Found 3 tests for numpy.dft.helper
  Found 36 tests for numpy.core.ma
  Found 10 tests for numpy.lib.twodim_base
  Found 10 tests for numpy.core.defmatrix
  Found 1 tests for numpy.lib.ufunclike
  Found 39 tests for numpy.lib.function_base
  Found 1 tests for numpy.lib.polynomial
  Found 8 tests for numpy.core.records
  Found 26 tests for numpy.core.numeric
  Found 4 tests for numpy.lib.index_tricks
  Found 46 tests for numpy.lib.shape_base
  Found 0 tests for __main__
...................................................................................F..F.............................................................................................................................................................................................................................................................................................................................................................................................
======================================================================
FAIL: check_large_types (numpy.core.tests.test_scalarmath.test_power)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy/core/tests/test_scalarmath.py",
line 47, in check_large_types
    assert b == 6765201, "error with %r: got %r" % (t,b)
AssertionError: error with <type 'float128scalar'>: got 0.0

======================================================================
FAIL: check_types (numpy.core.tests.test_scalarmath.test_types)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy/core/tests/test_scalarmath.py",
line 20, in check_types
    assert a == 1, "error with %r: got %r" % (atype,a)
AssertionError: error with <type 'float128scalar'>: got 0.0

----------------------------------------------------------------------
Ran 468 tests in 1.658s

FAILED (failures=2)
<unittest.TextTestRunner object at 0x10bab90>
===================

On 7/25/06, Damien Miller <dj...@mi...> wrote:
> On Fri, 21 Jul 2006, Travis Oliphant wrote:
>
> >
> > I've created the 1.0b1 release tag in SVN and will be uploading files
> > shortly to Sourceforge.
>
> FYI numpy-1.0b1 builds fine and passes all its regression tests
> on OpenBSD -current.
>
> -d
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>


-- 
Rudolph van der Merwe

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Steve L. <lis...@ar...>]

Hi Rudolph,

> I just built numpy-1.0b1 on Mac OS X (10.4.7) using gcc 4.0 and it
> fails 2 of the regression tests. Here is the output:

I actually posted about this a few days ago ... which also almost got  
lost in the sink, but David Cooke replied to me last night to say  
that they are aware of the problem.

http://projects.scipy.org/scipy/numpy/ticket/183

They suspect that it's a gcc4 problem .. I did try to recompile numpy  
last night using gcc3.3 but I'm still having the same issues ...  
so ... that's all I know right now :-)

-steve

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Robert K. <rob...@gm...>]

Travis Oliphant wrote:
> I've created the 1.0b1 release tag in SVN and will be uploading files 
> shortly to Sourceforge.
> 
> I've also created a 1.0 release branch called ver1.0
> 
> The trunk is now version 1.1 of NumPy and should be used for 
> new-development only.  I don't expect 1.1 to come out for at least a year.
> 
> Bug-fixes and small changes can happen on the 1.0 branch.  These will be 
> merged periodically to 1.1 or vice-versa.  But, the 1.0 branch will be 
> used for releases for the next year.
 >
 > AFAIK, this is similar to Python's release plan.

Let's not make a branch until 1.0 is actually out and we are making 1.0.x 
releases. It's confusing since at the moment, the trunk is not getting any 
activity. It's not the main trunk of development. Some people have already come 
to the list confused about where to get the code with fixes to the bugs they've 
reported. The branches are getting too far diverged at the moment. It's going to 
be hell merging them, and we are going to lose the revision history when we do 
merge. The revision messages won't be joined with the the changes they talk about.

In point of example, Python development for a 2.x version goes on the trunk 
until the actual release of 2.x. Then a 2.x branch is created for maintainings 
2.x.y and the trunk develops for 2.x+1. We aren't going to be working on 1.1 
until 1.0 is actually out the door.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[David M. C. <co...@ph...>]

On Wed, 26 Jul 2006 11:14:42 -0500
Robert Kern <rob...@gm...> wrote:

> Travis Oliphant wrote:
> > I've created the 1.0b1 release tag in SVN and will be uploading files 
> > shortly to Sourceforge.
> > 
> > I've also created a 1.0 release branch called ver1.0
> > 
> > The trunk is now version 1.1 of NumPy and should be used for 
> > new-development only.  I don't expect 1.1 to come out for at least a year.
> > 
> > Bug-fixes and small changes can happen on the 1.0 branch.  These will be 
> > merged periodically to 1.1 or vice-versa.  But, the 1.0 branch will be 
> > used for releases for the next year.
>  >
>  > AFAIK, this is similar to Python's release plan.
> 
> Let's not make a branch until 1.0 is actually out and we are making 1.0.x 
> releases. It's confusing since at the moment, the trunk is not getting any 
> activity. It's not the main trunk of development. Some people have already
> come to the list confused about where to get the code with fixes to the
> bugs they've reported. The branches are getting too far diverged at the
> moment. It's going to be hell merging them, and we are going to lose the
> revision history when we do merge. The revision messages won't be joined
> with the the changes they talk about.

That's one reason that I'm careful (or least try to be) in my change messages
to mention the ticket number for the bug fixed in the first line, so that
Trac will show it in the source browser, and to mention the revision number
of the fix in the ticket itself. The comment for stuff merged from one branch
to the other mentions which revisions are being merged from the original
branch (again, on the first line so Trac will see it). If applicable, add the
merge to the ticket also.

Merging a bug fix between trunks as soon as possible is a good idea too!

Then it's a relatively simple matter to browse through Trac and see what's
been merged, and what commits fix which.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Robert K. <rob...@gm...>]

David M. Cooke wrote:
> That's one reason that I'm careful (or least try to be) in my change messages
> to mention the ticket number for the bug fixed in the first line, so that
> Trac will show it in the source browser, and to mention the revision number
> of the fix in the ticket itself. The comment for stuff merged from one branch
> to the other mentions which revisions are being merged from the original
> branch (again, on the first line so Trac will see it). If applicable, add the
> merge to the ticket also.
> 
> Merging a bug fix between trunks as soon as possible is a good idea too!
> 
> Then it's a relatively simple matter to browse through Trac and see what's
> been merged, and what commits fix which.

The problem is that it's still a lot of work keeping two branches in sync with 
each other over long periods of time. Until 1.0 final goes out, everything 
getting checked into the 1.0 branch should also be on the trunk. Once 1.0 final 
is out and the 1.0.x maintenance series begins, that's the time to branch since 
the branch is then intended to be different from the trunk.

My experience with long-lived branches is quite bad. They've caused me a lot of 
problems at work.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] I've created a 1.0b1 release tag in SVN

[Travis O. <oli...@ie...>]

Robert Kern wrote:
> Let's not make a branch until 1.0 is actually out and we are making 1.0.x 
> releases. It's confusing since at the moment, the trunk is not getting any 
> activity. It's not the main trunk of development. Some people have already come 
> to the list confused about where to get the code with fixes to the bugs they've 
> reported. The branches are getting too far diverged at the moment. It's going to 
> be hell merging them, and we are going to lose the revision history when we do 
> merge. The revision messages won't be joined with the the changes they talk about.
>   

This is sound reasoning.  I was way too pre-mature in making a ver1.0 
branch.  I had thought that backward incompatible changes would go into 
the trunk and the ver1.0 branch would be more or less stable.  But this 
was not a wise move as I'm beginning to see.   If somebody wants to 
experiment with a change, they can make a branch...

The trunk should be the main line of development.   I apologize for my 
stumbling over these software-release issues.  I'm really not a 
software-manager at heart --- do we have any volunteers for a 
release-manager :-)

I'm going to re-number the trunk to 0.9.9. 

I'm also going to delete the ver1.0 branch and chalk that up to a 
learning mistake.

We will make a 1.0 branch for building maintenance releases from as soon 
as 1.0 comes out officially which won't be for a few months --- Let's 
target the first of October, for now.


-Travis