[Numpy-discussion] Oops - maybe post3 numpy file?

Post by Matthew Brett
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0.
Using twine to do the upload generated a new release - 1.10.0.post2 -
containing only the wheels. I deleted that new release to avoid
confusion, but now, when I try and upload the wheels to the 1.10.0
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,

Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I
think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

Chuck

j***@gmail.com

2015-10-09 01:19:48 UTC

If you manage a release without a `post` post-fix, then I would not have to
worry right away about what to do about a statsmodels setup.py that cannot
handle it.

Josef

Post by Charles R Harris
Chuck
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Charles R Harris

2015-10-09 01:28:08 UTC

On Thu, Oct 8, 2015 at 8:39 PM, Charles R Harris <

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,
I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

If you manage a release without a `post` post-fix, then I would not have
to worry right away about what to do about a statsmodels setup.py that
cannot handle it.

It's a learning experience all round :-) Might take a look at NumpyVersion
in numpy/lib if handling versioning is a problem. But... NumpyVersion is
buggy also

In [7]: NumpyVersion('1.10.0.post1') < '1.10.0'
Out[7]: True

<snip>

Chuck
<https://mail.scipy.org/mailman/listinfo/numpy-discussion>

Nathaniel Smith

2015-10-09 01:26:39 UTC

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,

I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

I vote that we increment the micro number every time we upload a new source
release, and reserve the postN suffix for binary-only uploads. If this
means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we
probably won't run out of numbers :-).

-n

Charles R Harris

2015-10-09 01:32:12 UTC

version.

Post by Matthew Brett
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,

I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.
I vote that we increment the micro number every time we upload a new
source release, and reserve the postN suffix for binary-only uploads. If
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we
probably won't run out of numbers :-).

The only difference between 1.10.0 and 1.10.0.post2 is that the latter is
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

Chuck

Matthew Brett

2015-10-09 02:45:57 UTC

Hi,

On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,
I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

I vote that we increment the micro number every time we upload a new
source release, and reserve the postN suffix for binary-only uploads. If
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we
probably won't run out of numbers :-).

The only difference between 1.10.0 and 1.10.0.post2 is that the latter is
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

Is the summary this:

* never have an actual numpy version .postN;
* releases always have source with a clean Major.Minor.Micro release number;
* binary packages for Minor.Minor.Micro release numbers may have
filenames ending in .postN
* these binary packages should be uploaded via the web interface to
avoid creating a new release

?

Matthew

Ralf Gommers

2015-10-09 10:28:58 UTC

Post by Matthew Brett
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris

On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <

Yeah, pipy is why we are on post2 already. Given the problem with

msvc9,

I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions,

decisions.

I'll see if Julian has anything to say in the morning and go from

there.

Post by Nathaniel Smith
I vote that we increment the micro number every time we upload a new
source release, and reserve the postN suffix for binary-only uploads. If
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 --

Post by Nathaniel Smith
probably won't run out of numbers :-).

The only difference between 1.10.0 and 1.10.0.post2 is that the latter is
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

* never have an actual numpy version .postN;
* releases always have source with a clean Major.Minor.Micro release number;
* binary packages for Minor.Minor.Micro release numbers may have
filenames ending in .postN

The few times in the past when we've needed to fix a binary, we've just
re-uploaded it with the same name. This seems much preferable to me than
confusing users with a post-fix on PyPi that doesn't even match
``numpy.__version__`` and that is so uncommon that I've never seen it used
anywhere.

If re-uploading with the same name is now disallowed by PyPi (is it?) then
bumping the micro version number as Nathaniel proposes would be the way to
go imho.

Ralf

Post by Matthew Brett
* these binary packages should be uploaded via the web interface to
avoid creating a new release
?
Matthew
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Charles R Harris

2015-10-09 14:43:50 UTC

Post by Matthew Brett
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris

On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <

Post by Matthew Brett
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0.
Using twine to do the upload generated a new release - 1.10.0.post2

Post by Matthew Brett
containing only the wheels. I deleted that new release to avoid
confusion, but now, when I try and upload the wheels to the 1.10.0
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,

Yeah, pipy is why we are on post2 already. Given the problem with

msvc9,

I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions,

decisions.

I'll see if Julian has anything to say in the morning and go from

there.

Post by Nathaniel Smith
I vote that we increment the micro number every time we upload a new
source release, and reserve the postN suffix for binary-only uploads.

Post by Nathaniel Smith
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2

-- we

Post by Nathaniel Smith
probably won't run out of numbers :-).

The only difference between 1.10.0 and 1.10.0.post2 is that the latter

Post by Charles R Harris
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

The few times in the past when we've needed to fix a binary, we've just
re-uploaded it with the same name. This seems much preferable to me than
confusing users with a post-fix on PyPi that doesn't even match
``numpy.__version__`` and that is so uncommon that I've never seen it used
anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?) then
bumping the micro version number as Nathaniel proposes would be the way to
go imho.

You are not allowed to reuse a file name, and numpy.__version__ must match
the file name or pip install will fail. This has all been a bit of
experimentation and I think we have learned something. Agree about not
using the `.postN` suffix. I expect we will have fewer problems next time
around.

Chuck

Matthew Brett

2015-10-09 18:17:15 UTC

On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris

Post by Matthew Brett
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris

On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,
I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

The only difference between 1.10.0 and 1.10.0.post2 is that the latter is
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

The few times in the past when we've needed to fix a binary, we've just
re-uploaded it with the same name. This seems much preferable to me than
confusing users with a post-fix on PyPi that doesn't even match
``numpy.__version__`` and that is so uncommon that I've never seen it used
anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?) then
bumping the micro version number as Nathaniel proposes would be the way to
go imho.

You are not allowed to reuse a file name, and numpy.__version__ must match
the file name or pip install will fail. This has all been a bit of
experimentation and I think we have learned something. Agree about not using
the `.postN` suffix. I expect we will have fewer problems next time around.

OK - any chance of a 1.10.1 release urgently? Otherwise the wheel
installs don't work on OSX...

Matthew

Charles R Harris

2015-10-09 18:54:46 UTC

Post by Matthew Brett
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris

Post by Matthew Brett
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris

On Oct 8, 2015 5:39 PM, "Charles R Harris" <

On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett

Post by Matthew Brett
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy

1.10.0.

Post by Matthew Brett
Using twine to do the upload generated a new release -

1.10.0.post2

Post by Matthew Brett
-
containing only the wheels. I deleted that new release to avoid
confusion, but now, when I try and upload the wheels to the

1.10.0

Post by Matthew Brett
Error processing form
This filename has previously been used, you should use a

different

Post by Matthew Brett
version.
Any chance of a post3 upload so I can upload some matching

wheels?

Post by Matthew Brett
Sorry about that,

Yeah, pipy is why we are on post2 already. Given the problem with msvc9,
I think we are due for 1.10.1 in a day or two. Or, I could revert the
troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions.
I'll see if Julian has anything to say in the morning and go from there.

I vote that we increment the micro number every time we upload a new
source release, and reserve the postN suffix for binary-only

uploads.

If
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we
probably won't run out of numbers :-).

The only difference between 1.10.0 and 1.10.0.post2 is that the

latter

Post by Charles R Harris
is
signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
document. Matthew, can you take care of that?

used

Post by Ralf Gommers
anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?)

then

Post by Ralf Gommers
bumping the micro version number as Nathaniel proposes would be the way

Post by Ralf Gommers
go imho.

You are not allowed to reuse a file name, and numpy.__version__ must

match

Post by Charles R Harris
the file name or pip install will fail. This has all been a bit of
experimentation and I think we have learned something. Agree about not

using

Post by Charles R Harris
the `.postN` suffix. I expect we will have fewer problems next time

around.
OK - any chance of a 1.10.1 release urgently? Otherwise the wheel
installs don't work on OSX...

Working on it. There is a problem with msvc9 that needs to be addressed,
otherwise it would be out already.

Chuck

Matthew Brett

2015-10-09 19:18:02 UTC

On Fri, Oct 9, 2015 at 11:54 AM, Charles R Harris

Post by Matthew Brett
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris

Post by Matthew Brett
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris