Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 28, 2007, at 1:36 PM, Dieter Maurer wrote:
...

Your example:

 You have release 1.1.

 You start working on the next release: 1.2dev-r#.

 Someone fixes a bug in 1.1 and releases 1.1.1.

With quite high probability, the bug fix should go as well into
the 1.2 development.

Thus, the problem you describe (1.1.1 is newer than 1.2dev-r;
but it treated as older then 1.2dev by 'setuptools')
has an effect only for a very limited time -- the time until
the fix (1.1 -- 1.1.1) went into the 1.2dev release, which
would probably become some 1.2dev-r!.


Sure, but that time could stretch out quite a bit.  I suppose that  
this problem somewhat inherent in having multiple release branches.   
For example, whatever we do, there will always be the possibility  
that an x.y.z release could have fixes in it that aren't in an x.y+1  
release yet, especially if x.y is a non-final release.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 27, 2007, at 4:45 AM, Philipp von Weitershausen wrote:


On 27 Sep 2007, at 02:29 , Tres Seaver wrote:

Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.

I'm *not* kidding about that:  taking shortcuts durng the release
process transfers pain / cost to everyone downstream.


Amen, brother. Well said.


+1

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 27, 2007, at 7:18 AM, Philipp von Weitershausen wrote:


On 27 Sep 2007, at 13:07 , Martijn Faassen wrote:

On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]

Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.

I'm *not* kidding about that:  taking shortcuts durng the release
process transfers pain / cost to everyone downstream.


While I fully agree that releases should be done with care and
attention, and that doing bad releases creates pain/cost for
everybody, this line of argumentation can be used to back up any form
of complication to the release process. :)

Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask is that really
necessary? for steps in the release process. Just weigh the pros and
cons. I'd like to understand more about the trouble Philipp ran into
doing releases from the original checkout and then tagging.


I've summarized this in another thread [1], but I'll be happy to  
elaborate here:


* People actually forget to make the tag. This happened to Roger  
the other day. It happened to Jim before with zc.buildout. I'm not  
mentioning their names to point fingers. I'm just pointing out that  
people who've been with us for a long time forget. If the process  
said they should actually check out the tag, they'll hardly forget.


Having a script we have to mindlessly follow will help.

* People create the wrong tags or tags in the wrong places. This  
happened to Jim the other day with ZODB 3.7.1. Again, I'm not  
blaming him. But I believe if he had to check out the tag to make  
the release, he would've caught his mistake.


I doubt it.  I would have probably just rereleased 3.7.1, possibly  
with 3.7.2 uselessly included.


* People forget to clean up the 'build' directory. This happened to  
me the other day. Let me elaborate: I have a trunk checkout of  
zopeproject that I use to develop it. Whenever I wanted to make a  
release, I'd just prepare it, tag it and generate the distributino  
from the trunk checkout. The problem was that I had moved stuff  
around, but the old stuff was still making it to the egg because it  
still sat around in the 'build' direcdtory that distutils leaves. I  
know it sucks that distutils doesn't clean up after itself, but  
that's just the way it is. If you're forced to use a clean  
checkout, this can't happen.


The build directory is really annoying.

* People forget to check in important files. This happened to Baiju  
the other day. He created a CHANGES.txt file and referred to it  
from setup.py. The only problem is that he forgot to check it in.  
It can happen, I'm not blaming him. The problem is that setuptools  
looks at which files are in svn in order to create the archive  
manifest. So CHANGES.txt wasn't in the tarball and the egg was  
completely uninstallable (because setup.py couldn't be executed  
since CHANGES.txt was missing).


These are four separate cases where I've actually witnessed myself  
or other people mess up. We're forgetful, we can't do anything  
about that. We can, however, force us to catch our mistakes. I  
believe that if we made everybody create the tarballs from the tag,  
it would improve the situation a lot.


I'm beginning to see a consensus that we should make it impossible  
to create distributions from the trunk or a release branch.


Yup. BTW, I find it helpful to test source releases by unpacking them  
and seeing if I can build eggs from the unpacked source.  Of course,  
it would be even better to run the tests.  I suspect that a buildout  
feature could automate this.  Something along the lines of a buildout  
command that: creates distros from the listed develop directories and  
then installs those distros rather than the develop eggs so that  
tests could be run against the distros.  This would probably be  
something good to do when I have some time to get back to buildout.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 27, 2007, at 7:37 AM, Philipp von Weitershausen wrote:


On 27 Sep 2007, at 12:20 , Stephan Richter wrote:
egg_info does not validate the trove classifiers, for example. I  
tried this

last night before writing this mail.


Well, to be honest, I wonder how you can mess up with the  
classifiers. I just always copy them from http://pypi.python.org/ 
pypi?%3Aaction=list_classifiers. Anything else is just insane...


The classifiers are a PITA.  I suspect we should be very restrictive  
in using them.


It's especially annoying that release status can generally be  
inferred from the version number.


I'm beginning to wonder if we should have some setuptools extensions  
that automate some of these things,


Another idea I've been thinking about is a custom index that is used  
rather than PyPI.  The main motivation was to automate management of  
non-public distributions, but such a front end could also automate  
some aspects of releases that setuptools doesn't handle.


But, if you wish for such a tool, let your wish be my command. With  
the attached verifyclassifiers.py script, you may do so using the  
following command:


  python setup.py --classifiers | python verifyclassifiers.py


Cool.

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 6:14 PM, Jim Fulton wrote:
...
I agree that the develop egg case is problematic.  I'd like to  
think about that.


Well, I thought and I thought 

I could probably arrange that develop eggs created by buildout got  
their versions from the buildout spec. Something like:


  [buildout]
  develop =
 . ==1.4
 foo ==2.1

This would override whatever version was given in setup.py.

This wouldn't help people who don't develop with buildout though.

Alternatively, we could add some API that would allow our setup files  
to take a --version argument.


So our setup files on the trunk or branches might have something like:

  setup(
 version = comman_line_version()

or something.  I'm not an expert on extending setuptools.

I'm somewhat pessimistic about getting new features in setuptools as  
0.7 seems to have fairly grandiose objectives.  There don't seem to  
be incremental feature releases planned. :(


I have a feeling that we/I should learn how to extend setuptools to  
get the features we need.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 27 Sep 2007, at 02:29 , Tres Seaver wrote:

Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.

I'm *not* kidding about that:  taking shortcuts durng the release
process transfers pain / cost to everyone downstream.


Amen, brother. Well said.

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 27 Sep 2007, at 04:52 , Stephan Richter wrote:

On Wednesday 26 September 2007 20:35, Tres Seaver wrote:
So I usually create the release first and upload it and after  
that create

the tag.


-100.  Get it right, check it in, *then* upload the distribution.


We do not have the tools. There is simply no telling beforehand.  
Marius and I

worked on the ideas of a  tool that he proposed earlier today.


There is some telling beforehand:

* As I already said, you can generate all the package metadata with

python setup.py egg_info

  and then inspect it in src/EGG.egg-info/PKG-INFO. This is  
equivalent to checking
  the PyPI page, it contains the same information. I frequently do  
this, also to make
  sure my setup.py actually executes before I tag (I often forget a  
comma or so.)


* You can generate an egg or a tarball locally, without uploading it.  
Then you can
  take a look at the tarball or the egg. Unzip it if necessary. Call  
python setup.py
  egg_info inside the tarball, if necessary, to see if all the  
CHANGES.txt, README.txt
  etc. files are there as well, especially when you know you messed  
this part up

  before.

  You could also easy_install the egg and/or tarball in a virtualenv  
(so that your

  global site-packages won't be affected).

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Thursday 27 September 2007 05:14, Philipp von Weitershausen wrote:

 There is some telling beforehand:

 * As I already said, you can generate all the package metadata with

  python setup.py egg_info

and then inspect it in src/EGG.egg-info/PKG-INFO. This is
 equivalent to checking
the PyPI page, it contains the same information. I frequently do
 this, also to make
sure my setup.py actually executes before I tag (I often forget a
 comma or so.)

egg_info does not validate the trove classifiers, for example. I tried this 
last night before writing this mail. If the the setup.py file has a syntax 
error, I will know about it when running buildout.

 * You can generate an egg or a tarball locally, without uploading it.
 Then you can
take a look at the tarball or the egg. Unzip it if necessary. Call
 python setup.py
egg_info inside the tarball, if necessary, to see if all the
 CHANGES.txt, README.txt
etc. files are there as well, especially when you know you messed
 this part up
before.

Still does not solve my problem use case.

You could also easy_install the egg and/or tarball in a virtualenv
 (so that your
global site-packages won't be affected).

I still do not see how this solves the problem.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
 Further, anybody who finds the effort of creating a fresh' checkout
 bevore making a release too burdensome should consider themselves
 self-selected out of the release manager pool.

 I'm *not* kidding about that:  taking shortcuts durng the release
 process transfers pain / cost to everyone downstream.

While I fully agree that releases should be done with care and
attention, and that doing bad releases creates pain/cost for
everybody, this line of argumentation can be used to back up any form
of complication to the release process. :)

Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask is that really
necessary? for steps in the release process. Just weigh the pros and
cons. I'd like to understand more about the trouble Philipp ran into
doing releases from the original checkout and then tagging.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Philipp von Weitershausen wrote:

On 27 Sep 2007, at 13:07 , Martijn Faassen wrote:

[snip]

Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask is that really
necessary? for steps in the release process. Just weigh the pros and
cons. I'd like to understand more about the trouble Philipp ran into
doing releases from the original checkout and then tagging.


I've summarized this in another thread [1], but I'll be happy to 
elaborate here:

[snip]
These are four separate cases where I've actually witnessed myself or 
other people mess up. We're forgetful, we can't do anything about that. 
We can, however, force us to catch our mistakes. I believe that if we 
made everybody create the tarballs from the tag, it would improve the 
situation a lot.


I'm beginning to see a consensus that we should make it impossible to 
create distributions from the trunk or a release branch.


Thanks, very clear. You convinced me. Even if distutils would start 
cleaning up after itself the other issues still stand and won't be going 
away.


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 27 Sep 2007, at 12:20 , Stephan Richter wrote:
egg_info does not validate the trove classifiers, for example. I  
tried this

last night before writing this mail.


Well, to be honest, I wonder how you can mess up with the  
classifiers. I just always copy them from http://pypi.python.org/pypi? 
%3Aaction=list_classifiers. Anything else is just insane...


But, if you wish for such a tool, let your wish be my command. With  
the attached verifyclassifiers.py script, you may do so using the  
following command:


  python setup.py --classifiers | python verifyclassifiers.py

If the the setup.py file has a syntax error, I will know about it  
when running buildout.


True, but running buildout can take a long time.


* You can generate an egg or a tarball locally, without uploading it.
  Then you can take a look at the tarball or the egg. Unzip it if  
necessary. Call
  python setup.py egg_info inside the tarball, if necessary, to  
see if all the
  CHANGES.txt, README.txt etc. files are there as well, especially  
when you know

  you messed this part up before.


Still does not solve my problem use case.


   You could also easy_install the egg and/or tarball in a virtualenv
   (so that your global site-packages won't be affected).


I still do not see how this solves the problem.


They're measures for making sure the distribution has the right  
metadata and is easy_install'able. What other problem do we have?



import sys
import urllib2

url = 'http://pypi.python.org/pypi?%3Aaction=list_classifiers'
file = urllib2.urlopen(url)
valid_classifiers = file.read().splitlines()

for classifier in sys.stdin:
classifier = classifier.rstrip() # cut of new line at the end
if classifier not in valid_classifiers:
print sys.stderr, Invalid classifier:, classifier


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
 These are four separate cases where I've actually witnessed myself or  
 other people mess up. We're forgetful, we can't do anything about  
 that. We can, however, force us to catch our mistakes. I believe that  
 if we made everybody create the tarballs from the tag, it would  
 improve the situation a lot.

Of course, an additional or other approach would be to implement a tool that 
checks various things. I agree that the problems you listed are solvable with 
doing the release from the tag, but there are cases that are not caught:

1. In your last case, if bajium would have used svn switch --relocate the 
file would still be around and the release would work. I imagine that most 
people would use svn switch because making another checkout is just a 
package management mess.

2. My Trove classifier problem is not solved either using this approach. 
Contrary to what Tres hinted on in his E-mail , if there are errors while 
registering with PyPI, no new release is added. Also, buildout setup . 
egg_info does not verify the Trove classifiers. (Note that I think the Trove 
classifiers are only one example of something going wrong.)

3. A serious problem occurs, if you accidentally specify the wrong package 
name and version in setup.py. Both happened to me yesterday, but I caught it 
in time.

A fairly simple tool can find and report all the problems found and offer 
assistance. I think it is worth investing in one, especially since it will 
reduce my overhead since my manual checking now becomes automated.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/27/07, Stephan Richter [EMAIL PROTECTED] wrote:
 On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
[snip]
 A fairly simple tool can find and report all the problems found and offer
 assistance. I think it is worth investing in one, especially since it will
 reduce my overhead since my manual checking now becomes automated.

Agreed a tool could be helpful in this case as well.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 27 Sep 2007, at 13:47 , Stephan Richter wrote:

On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:

These are four separate cases where I've actually witnessed myself or
other people mess up. We're forgetful, we can't do anything about
that. We can, however, force us to catch our mistakes. I believe that
if we made everybody create the tarballs from the tag, it would
improve the situation a lot.


Of course, an additional or other approach would be to implement a  
tool that
checks various things. I agree that the problems you listed are  
solvable with
doing the release from the tag, but there are cases that are not  
caught:


1. In your last case, if bajium would have used svn switch -- 
relocate the
file would still be around and the release would work. I imagine  
that most
people would use svn switch because making another checkout is  
just a

package management mess.


Why is making another checkout a package management mess? Go to /tmp  
or ~/temp or whatever, get the checkout, do your release stuff and  
delete it again. Is this so hard? Sorry, but I fail to see how this  
is messy.


Also, regardless of what you imagine people do, if the process says  
get a new, fresh checkout then this is what people should do. If  
they use svn switch instead, then they're not following the process.  
End of story.


2. My Trove classifier problem is not solved either using this  
approach.
Contrary to what Tres hinted on in his E-mail , if there are errors  
while
registering with PyPI, no new release is added. Also, buildout  
setup .
egg_info does not verify the Trove classifiers. (Note that I think  
the Trove

classifiers are only one example of something going wrong.)


buildout setup? I've never seen that. I can't find any documentation  
on it in zc.buildout. How does it work? Does it call setup.py for  
every development egg in buildout.cfg? Why not just call python  
setup.py?


Anyway, I think the Trove classifiers are an edge case. I've never  
seen anyone get those wrong before, to be honest. I *have* seen  
people get other things wrong and I think these problems would all be  
solved if we made it impossible to create distributions from a branch  
or the trunk, but made people create them from tags instead.


3. A serious problem occurs, if you accidentally specify the wrong  
package
name and version in setup.py. Both happened to me yesterday, but I  
caught it

in time.


I assume you mean the egg name, not the package name.

I'm not sure how a tool could help you here. I suppose it could use  
some conventions (e.g. look at the packages inside the egg) or look  
at the subversion URL.


A fairly simple tool can find and report all the problems found and  
offer
assistance. I think it is worth investing in one, especially since  
it will

reduce my overhead since my manual checking now becomes automated.


I'm not arguing against such a tool. If you are willing to come up  
with it, go for it. We should still have a proper *human* process  
first. A tool can then help us do the tedious bits.




___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Baiju M]

Philipp von Weitershausen wrote:

 On 27 Sep 2007, at 13:47 , Stephan Richter wrote:
 On Thursday 27 September 2007 07:18, Philipp von Weitershausen
 wrote:
 These are four separate cases where I've actually witnessed
 myself or other people mess up. We're forgetful, we can't do
 anything about that. We can, however, force us to catch our
 mistakes. I believe that if we made everybody create the tarballs
 from the tag, it would improve the situation a lot.

 Of course, an additional or other approach would be to implement a
 tool that checks various things. I agree that the problems you
 listed are solvable with doing the release from the tag, but there
 are cases that are not caught:

 1. In your last case, if bajium would have used svn switch
 --relocate the file would still be around and the release would
 work. I imagine that most people would use svn switch because
 making another checkout is just a package management mess.

 Why is making another checkout a package management mess? Go to /tmp
 or ~/temp or whatever, get the checkout, do your release stuff and
 delete it again. Is this so hard? Sorry, but I fail to see how this
 is messy.

 Also, regardless of what you imagine people do, if the process says
 get a new, fresh checkout then this is what people should do. If
 they use svn switch instead, then they're not following the process.
 End of story.


Release from a fresh tag check out is always good.

personal
I have released eggs before and after my mistake.   After my mistake,
I created check list for my convenience here:
http://wiki.zope.org/zope3/BaijuMuthukadan
An now I am making release from tag checkouts.
/personal

Regards,
Baiju M


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
...

If we are going to have a change log, which we should, I would prefer
it to be included in source distributions.


I want them present in the *installed* egg, not just in the source
distribution:  setuptools doesn't preserve source distributions after
creating / installing the '.egg' version.


Agreed, but


 Including a file other
that README in the root requires extra effort that I don't want to
require -- writing setup.py files is hard enough as it is.


Put the real README.txt and CHANGES.txt in the actual package:  the
version which is a peer of 'setup.py' should be a stub which points to
the real versions.


I can live with this, but I don't like it.  It feels more complicated  
to me.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote:

 On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
[snip]
   Including a file other
  that README in the root requires extra effort that I don't want to
  require -- writing setup.py files is hard enough as it is.
 
  Put the real README.txt and CHANGES.txt in the actual package:  the
  version which is a peer of 'setup.py' should be a stub which points to
  the real versions.

 I can live with this, but I don't like it.  It feels more complicated
 to me.

I don't like it either. I thought we resolved this though so I'm not
sure why we're discussing this. CHANGES.txt in the root dir it is,
right?

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Hey,
 
 On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote:
 On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
 [snip]
  Including a file other
 that README in the root requires extra effort that I don't want to
 require -- writing setup.py files is hard enough as it is.
 Put the real README.txt and CHANGES.txt in the actual package:  the
 version which is a peer of 'setup.py' should be a stub which points to
 the real versions.
 I can live with this, but I don't like it.  It feels more complicated
 to me.
 
 I don't like it either. I thought we resolved this though so I'm not
 sure why we're discussing this. CHANGES.txt in the root dir it is,
 right?

- -1.  I argued for putting the CHANGES.txt and the real README.txt in
the *package* dir, making them available in the *installed egg*, not
just the source ditribution.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG++AV+gerLs4ltQ4RAv11AJ48x6iioc9AWavIZS5zvQvpR/X1dwCgsuro
3CvFwTcmCfYqXFpICxDGCxk=
=+T+6
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
  I don't like it either. I thought we resolved this though so I'm not
  sure why we're discussing this. CHANGES.txt in the root dir it is,
  right?

 - -1.  I argued for putting the CHANGES.txt and the real README.txt in
 the *package* dir, making them available in the *installed egg*, not
 just the source ditribution.

Okay, I hadn't read it that way as the word 'package' is ambiguous.
That seems completely against the way everybody else does this. Why is
having this available in the installed egg so important?

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Raphael Ritz wrote:
[snip]


I don't see this in conflict. Rather as complementing each other.


Yes, me too. We need human guidelines in any case.

Then we implement tools to help check the human procedure. If the tool 
makes some of the human guidelines unnecessary as the tool catches the 
errors instead, then we can adjust our human guidelines to say, you can 
also use the tool and skip this step. It depends on what the tool will 
be like.


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Hey,
 
 On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
 [snip]
 I don't like it either. I thought we resolved this though so I'm not
 sure why we're discussing this. CHANGES.txt in the root dir it is,
 right?
 - -1.  I argued for putting the CHANGES.txt and the real README.txt in
 the *package* dir, making them available in the *installed egg*, not
 just the source ditribution.
 
 Okay, I hadn't read it that way as the word 'package' is ambiguous.
 That seems completely against the way everybody else does this. Why is
 having this available in the installed egg so important?

Because it is a valuable clue to the guy scratching his head trying to
figure out why something isn't working after 'easy_install' runs:  the
source distribution is only around on his system transiently.

The changelog, along with the README is an essential part of the
package's documentation, and should be installed with the egg.  Because
distutils / setuptools doesn't allow for installing non-package data, we
have to put them in the package.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG++K2+gerLs4ltQ4RAqJsAJ4io55zfVQeYWeVwDiC72/VQS7LPwCfX7sO
tmi7zuaUDF3FHs9V3vpPh2w=
=wnDh
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Dieter Maurer]

Jim Fulton wrote at 2007-9-26 18:14 -0400:
 ...
 
We've just released 1.1. We guess the next release is 1.2.  We change  
things and release, 1.2dev-r#. Someone fixes a bug and releases  
1.1.1.  Now there's a dev release of 1.2 that is actually older than  
the 1.1.1 release but that setuptools considers to be newer.  I think  
this is fairly problematic.  Then again, I think that dev releases  
are problematic in a lot of ways.

In your example, it is likely, that the fix will also go into the
1.2 development branch. I.e. you will get an 1.2dev-r!
with !  #.



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 27, 2007, at 1:42 PM, Dieter Maurer wrote:


Jim Fulton wrote at 2007-9-26 18:14 -0400:

...

We've just released 1.1. We guess the next release is 1.2.  We change
things and release, 1.2dev-r#. Someone fixes a bug and releases
1.1.1.  Now there's a dev release of 1.2 that is actually older than
the 1.1.1 release but that setuptools considers to be newer.  I think
this is fairly problematic.  Then again, I think that dev releases
are problematic in a lot of ways.


In your example, it is likely, that the fix will also go into the
1.2 development branch. I.e. you will get an 1.2dev-r!
with !  #.


I'm not sure what you mean by my example or why what you said would  
be so.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

Stephan Richter wrote:

On Wednesday 26 September 2007 04:49, Christian Theune wrote:

The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.

I can reproduce the problem by creating the packages myself as ZIP files
(doesn't work) and then as tar files (does work).


Okay, thanks a lot for this research. So this is a problem that noone could 
anticipate. Roger tried the eggs on his machine and they worked there.


Yes, this is really a weird setuptools bug. Apparently it can't properly 
install package metadata from ZIP distributions on Linux and Mac.



So that's something we learned: We have to make tag.gz releases.


Yes. You can do this via

  python setup.py sdist --format=gztar


--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access

[Martijn Faassen]

Stephan Richter wrote:

On Wednesday 26 September 2007 04:16, Christian Theune wrote:

The whole list of things that might be relevant here is:

- zope.securitypolicy
- zope.session, zope.app.session
- zope.app.authentication
- zope.app.i18n
- zope.i18nmessageid
- zope.app.applicationcontrol
- zope.app.appsetup

I'll go through those now and try to fix it up.


I'll review those with Roger and fix what needs to be fixed.


This is IMHO a good example why we shouldn't go for 'everyone can make a
release'.


I totally disagree. If we trust people with repository access, then we have to 
trust them with release making. If you subscribe to the egg process, you have 
to do frequent releases.


I think tagging things in svn is a minimal requirement, though. I 
understood that some of this stuff wasn't tagged?


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access

[Stephan Richter]

On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
 I think tagging things in svn is a minimal requirement, though. I
 understood that some of this stuff wasn't tagged?

I agree. And Roger simply forgot. As Marius pointed out, as we do more 
releases, problems like this will occur frequently. Making mistakes is human, 
so let's develop a tool that does some basic checking.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access

[Philipp von Weitershausen]

Stephan Richter wrote:

On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:

I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?


I agree. And Roger simply forgot. As Marius pointed out, as we do more 
releases, problems like this will occur frequently. Making mistakes is human, 
so let's develop a tool that does some basic checking.


I'm not yet convinced that we will have more releases. We have more 
releases now because we're trying to get to stable versions. After that, 
the eggs are on their own and I think we'll make much less releases.


But even if we got more releases to do, I don't see the problem. With 
more releases we'd get more practice and make less mistakes.


One of the things we should realize in this process is that -- even 
though setuptools makes it so damn easy to register and uplaod stuff to 
PyPI -- releases are actually important business. They can't just be 
created in a jiffy. They require attention and concentration. And a 
well-defined process.



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Stephan Richter wrote:

On Wednesday 26 September 2007 05:02, Christian Theune wrote:

Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.


There is conflicting information here. :-) Some people say we need branches, 
others say we don't. 


I think it'd be good to have a tag in any case. A tag can always be 
converted into a branch later.


And where is an agreed-upon document that you have to 
list the next version in the setup.py file after the release? Because I 
disagree with that, since you cannot know the next version.


I disagree with too, for the same reason.

What about using CHANGES.txt, which we should be maintaining anyway?

Before making a release, change CHANGES.txt, and convert the section:

unreleased
--

Fixed bugs blah blah.

To:

3.5.1 (2007-09-26)
--

Fixed bugs blah blah.

That is, come up with a release number, a release date, update setup.py 
with the release number, and tag it.


Then, after the release, add in a new section:

unreleased
--

This way checking CHANGES.txt should tell you what's going on with 
releases. If someone forgot to do the last step, you see immediately 
something is wrong, as you want to add your change to the 'unreleased' 
section but there's nothing there yet. You can then reconstruct what 
happened from the cheeseshop or the tags, and put in a new 'unreleased' 
section.


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

Stephan Richter wrote:

On Wednesday 26 September 2007 05:02, Christian Theune wrote:

Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.


There is conflicting information here. :-) Some people say we need branches, 
others say we don't. And where is an agreed-upon document that you have to 
list the next version in the setup.py file after the release?


It's not agreed upon, it's just what I wrote down:

http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt

Back when I put it up for discussion, all I got was a huge discussion 
about PEP8, which is just a small and rather unimportant paragraph. 
Unfortunately it's somewhere towards the beginning of the file. I wonder 
if anybody read any further and got to the actually important stuff. Sigh.



Because I disagree with that, since you cannot know the next version.


You can always know the minimum version. If you just released 3.4.2, I 
think it's sensible to point the next release to 3.4.3. If you later 
decide that you really need a feature release, you can always bump to 
3.5.0a1 (which would be the first release in the 3.5.x series).



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 10:10, Martijn Faassen wrote:
 This way checking CHANGES.txt should tell you what's going on with
 releases. If someone forgot to do the last step, you see immediately
 something is wrong, as you want to add your change to the 'unreleased'
 section but there's nothing there yet. You can then reconstruct what
 happened from the cheeseshop or the tags, and put in a new 'unreleased'
 section.

Good point; of course I agree. :-) A well-maintained CHANGES.txt file is worth 
a lot.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access

[Jim Fulton]

Well said.

Jim

On Sep 26, 2007, at 10:10 AM, Philipp von Weitershausen wrote:


Stephan Richter wrote:

On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:

I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?
I agree. And Roger simply forgot. As Marius pointed out, as we do  
more releases, problems like this will occur frequently. Making  
mistakes is human, so let's develop a tool that does some basic  
checking.


I'm not yet convinced that we will have more releases. We have more  
releases now because we're trying to get to stable versions. After  
that, the eggs are on their own and I think we'll make much less  
releases.


But even if we got more releases to do, I don't see the problem.  
With more releases we'd get more practice and make less mistakes.


One of the things we should realize in this process is that -- even  
though setuptools makes it so damn easy to register and uplaod  
stuff to PyPI -- releases are actually important business. They  
can't just be created in a jiffy. They require attention and  
concentration. And a well-defined process.



--
http://worldcookery.com -- Professional Zope documentation and  
training

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com



--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

Martijn Faassen wrote:
And where is an agreed-upon document that you have to list the next 
version in the setup.py file after the release? Because I disagree 
with that, since you cannot know the next version.


I disagree with too, for the same reason.


I'm not saying you should foresee the future, but I think you can very 
well know the next *anticipated* version. Doing so has some benefits:


* We need *a* convention, otherwise people will either release an egg 
with the same version twice (this happened to Jim with the ZODB 
yesterday, due to the lack of a convention) or skip a release number 
because they both increment after and before a release (happened to 
Roger yesterday; it's harmless but confusing).


* It is a convention that setuptools encourages (third para in 
http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion)


* On the trunk, you'll know what release line it is for. Is it 3.4.x? Or 
3.5.x?


* Even more important, when the trunk was used for 3.4.x and now you 
want to add a feature and want to bump it to 3.5.x, you explicitly see 
this in setup.py. And then you know that you have to create a 3.4 branch 
before you do this.




What about using CHANGES.txt, which we should be maintaining anyway?
[snip]


These are very good points. My guide [1] already recommends this practice.

[1] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 10:10 AM, Martijn Faassen wrote:


Stephan Richter wrote:

On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1  
yesterday

evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting information here. :-) Some people say we need  
branches, others say we don't.


I think it'd be good to have a tag in any case. A tag can always be  
converted into a branch later.


Yup. I don't think there is disagreement about tags and we don't  
really need agreement on branches.




And where is an agreed-upon document that you have to list the  
next version in the setup.py file after the release? Because I  
disagree with that, since you cannot know the next version.


I disagree with too, for the same reason.

What about using CHANGES.txt, which we should be maintaining anyway?


I agree with a change log.  CHANGES.txt is difficult to get included  
in distributions.  Having one requires a more complex setup.py.  I'd  
rather recommend including a change log in README.txt.





Before making a release, change CHANGES.txt, and convert the section:

unreleased
--

Fixed bugs blah blah.

To:

3.5.1 (2007-09-26)
--

Fixed bugs blah blah.

That is, come up with a release number, a release date, update  
setup.py with the release number, and tag it.


Then, after the release, add in a new section:

unreleased
--

This way checking CHANGES.txt should tell you what's going on with  
releases. If someone forgot to do the last step, you see  
immediately something is wrong, as you want to add your change to  
the 'unreleased' section but there's nothing there yet. You can  
then reconstruct what happened from the cheeseshop or the tags, and  
put in a new 'unreleased' section.


I agree except for the location of the change log.

Jim

P.S. ZODB's NEWS.txt/History.txt aren't workable for me and I plan to  
switch ZODB to using a change log in it's readme.  Unfortunately,  
it's setup is so complex It will take me a largish chunk of time to  
unwind this.


--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
 Martijn Faassen wrote:
[snip]
  What about using CHANGES.txt, which we should be maintaining anyway?
  [snip]

 These are very good points. My guide [1] already recommends this practice.

 [1]
 http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt

I can't find my description of this practice in the guide. In
particular, the practice of using unreleased entries.

Note that if you already anticipate the version number, you can instead do this:

1.3.7 (unreleased)
---

And then change the unreleased to the date once you're releasing.

The method I describe above tries to make sure that some amount of
reconstruction can be done in case of mistakes.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Wednesday 26 September 2007 05:02, Christian Theune wrote:
 Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
 evening. The stable release was made from that without making a
 maintenance branch and bumping the trunk to 3.5.
 
 There is conflicting information here. :-) Some people say we need branches, 
 others say we don't. And where is an agreed-upon document that you have to 
 list the next version in the setup.py file after the release? Because I 
 disagree with that, since you cannot know the next version.

+1,  The trunk should *always* say 'unreleased' or 'trunk', except in
the five minutes before cutting a release tag (if not using a release
branch).  Release branches should have '-branch' or something appended
to the version, except just before cutting a release tag.

Anything else makes it too easy to cut a premature / broken release;
such mistakes are going to damange  our story if we don't get out ahead
of them.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+nGq+gerLs4ltQ4RAtrkAJoDIeCeHW3BVdlWYLklwf6MrOV2MwCgy43W
enYWkDaVC0IHZV4Fb0K7KDA=
=WGvo
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
 Hey,

 On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
  Martijn Faassen wrote:
 [snip]
   What about using CHANGES.txt, which we should be maintaining anyway?
   [snip]
 
  These are very good points. My guide [1] already recommends this practice.
 
  [1]
  http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt

 I can't find my description of this practice in the guide. In
 particular, the practice of using unreleased entries.

Now I did. It was in a section that didn't mention CHANGES.txt (other
areas do), so I didn't find it. So forget about my complaint, I'm
sorry.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Wednesday 26 September 2007 04:49, Christian Theune wrote:
 The issue is that the eggs were released as ZIP files and for some
 reason those don't work correctly with the data files.

 I can reproduce the problem by creating the packages myself as ZIP files
 (doesn't work) and then as tar files (does work).
 
 Okay, thanks a lot for this research. So this is a problem that noone could 
 anticipate. Roger tried the eggs on his machine and they worked there.
 
 So that's something we learned: We have to make tag.gz releases.

Why would we zip / tar files up by hand, rather than using 'setup.py sdist'?

 BTW, which OS so you use? Roger told me he did several releases with Windows 
 at Lovely Systems and all was fine there. But then everyone else at Lovely 
 has Macs.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+nKD+gerLs4ltQ4RAl66AKCtLSJDOAVavsYVpw9A5EgIq1zg+QCgy5jc
cjUVQfmRlkGYFqZtuCy8fUg=
=/bGl
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote:


On Wednesday 26 September 2007 10:40, Jim Fulton wrote:

What about using CHANGES.txt, which we should be maintaining anyway?


I agree with a change log.  CHANGES.txt is difficult to get included
in distributions.  Having one requires a more complex setup.py.  I'd
rather recommend including a change log in README.txt.


-1. I don't like that. We include CHANGES.txt via the long  
description; that's

good enough for me.


Do you think that the change log should be included in the distribution?

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 26 Sep 2007, at 16:49 , Martijn Faassen wrote:
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED]  
wrote:

Martijn Faassen wrote:

[snip]

What about using CHANGES.txt, which we should be maintaining anyway?
[snip]


These are very good points. My guide [1] already recommends this  
practice.


[1]
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ 
maintaining-software.txt


I can't find my description of this practice in the guide. In
particular, the practice of using unreleased entries.


It's way down at the bottom, under the Releasing software section.

Note that if you already anticipate the version number, you can  
instead do this:


1.3.7 (unreleased)
---

And then change the unreleased to the date once you're releasing.


That's exactly what the guide recommends.



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 10:53, Jim Fulton wrote:
 On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote:
  On Wednesday 26 September 2007 10:40, Jim Fulton wrote:
  What about using CHANGES.txt, which we should be maintaining anyway?
 
  I agree with a change log.  CHANGES.txt is difficult to get included
  in distributions.  Having one requires a more complex setup.py.  I'd
  rather recommend including a change log in README.txt.
 
  -1. I don't like that. We include CHANGES.txt via the long  
  description; that's
  good enough for me.

 Do you think that the change log should be included in the distribution?

I am indifferent about it. I cannot see a strong argument for having it in the 
release. Because people read the changes before deciding to download the 
package. On the other hand, package managers for Linux distributions will 
hate us, probably. ;-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 10:53, Tres Seaver wrote:
 Why would we zip / tar files up by hand, rather than using 'setup.py
 sdist'?

We use this, but on Windows it uses winzip by default. You have to specify 
the --format option as Philipp pointed out earlier.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access

[Stephan Richter]

On Wednesday 26 September 2007 10:10, Philipp von Weitershausen wrote:
 Stephan Richter wrote:
  On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
  I think tagging things in svn is a minimal requirement, though. I
  understood that some of this stuff wasn't tagged?
 
  I agree. And Roger simply forgot. As Marius pointed out, as we do more
  releases, problems like this will occur frequently. Making mistakes is
  human, so let's develop a tool that does some basic checking.

 I'm not yet convinced that we will have more releases. We have more
 releases now because we're trying to get to stable versions. After that,
 the eggs are on their own and I think we'll make much less releases.

I would not hold my breath on this one, but I have unsupported hope you are 
right. ;-)

 But even if we got more releases to do, I don't see the problem. With
 more releases we'd get more practice and make less mistakes.

This is logically incorrect. It is the same as saying: More guns make us 
safer.

The error rate would have to drop by the same factor the releases are 
increased, which I do not think will be the case, especially since more 
people are doing releasing now.,

 One of the things we should realize in this process is that -- even
 though setuptools makes it so damn easy to register and uplaod stuff to
 PyPI -- releases are actually important business. They can't just be
 created in a jiffy. They require attention and concentration. And a
 well-defined process.

I agree. But all the process in the world will not drop the error rate to 
zero. I think that Marius' tool suggestion is very good and I also think we 
should seriously look at how Linux distributions manage that process. Having 
some staging mechanism would be good.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote:
 
 On Wednesday 26 September 2007 10:40, Jim Fulton wrote:
 What about using CHANGES.txt, which we should be maintaining anyway?
 I agree with a change log.  CHANGES.txt is difficult to get included
 in distributions.  Having one requires a more complex setup.py.  I'd
 rather recommend including a change log in README.txt.
 -1. I don't like that. We include CHANGES.txt via the long  
 description; that's
 good enough for me.
 
 Do you think that the change log should be included in the distribution?

+10.  The cheeseshop metadata is not where I would expect to look for a
changelog;  having it readable there is only helpful *before* I've
downloaded.

FWIW, I think that both README.txt and CHANGES.txt should be package
data, so that they are discoverable after installing an egg.  The
top-level README.txt should be boilerplate, and point to those files
(the setup.py process can then stitch them all todgether).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+nfe+gerLs4ltQ4RApwzAJ9WjIb1eWRU1LZA8Tm6hAnVLgcnnwCgovHP
HlNNaXNmE8X/4nz4oVVpPmE=
=PqY/
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Marius Gedminas]

On Wed, Sep 26, 2007 at 11:16:46AM -0400, Tres Seaver wrote:
 Jim Fulton wrote:
  On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote:
  
  On Wednesday 26 September 2007 10:40, Jim Fulton wrote:
  What about using CHANGES.txt, which we should be maintaining anyway?
  I agree with a change log.  CHANGES.txt is difficult to get included
  in distributions.  Having one requires a more complex setup.py.  I'd
  rather recommend including a change log in README.txt.
  -1. I don't like that. We include CHANGES.txt via the long  
  description; that's
  good enough for me.
  
  Do you think that the change log should be included in the distribution?
 
 +10.  The cheeseshop metadata is not where I would expect to look for a
 changelog;  having it readable there is only helpful *before* I've
 downloaded.
 
 FWIW, I think that both README.txt and CHANGES.txt should be package
 data, so that they are discoverable after installing an egg.  The
 top-level README.txt should be boilerplate, and point to those files
 (the setup.py process can then stitch them all todgether).

Example from Debian: all packages have a /usr/share/doc/$packagename
with the changelog and readme in there, and this is a Very Good Thing.

+1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt

+1 for the latest changelog entries visible on the cheeseshop page (see
an announcement, go to cheeseshop, see whether you want to upgrade or
not)

+1 for README.txt and CHANGES.txt available to you after you install an
egg.

Marius Gedminas
-- 
Despite all appearances, your boss is a thinking, feeling, human being.


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

Marius Gedminas wrote:
[snip]

+1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt

+1 for the latest changelog entries visible on the cheeseshop page (see
an announcement, go to cheeseshop, see whether you want to upgrade or
not)

+1 for README.txt and CHANGES.txt available to you after you install an
egg.


+1 for those too.

What does one need to tell setup.py to make sure CHANGES.txt is 
available? I understand it isn't by default, then? Hm, it does appear to 
be there by default. I checked grok 0.10's tgz and it's there, and we 
didn't do anything special.


I don't understand Jim's objections to a separate CHANGES.txt then. Is 
it just because it's more work to include the changes on the cheeseshop 
homepage if you separate out the text over multiple files?


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Fred Drake]

On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
 What does one need to tell setup.py to make sure CHANGES.txt is
 available? I understand it isn't by default, then? Hm, it does appear to
 be there by default. I checked grok 0.10's tgz and it's there, and we
 didn't do anything special.

Do you mean available in the unpacked sdist, or as part of the
installation?  I don't think any of README, README.txt, CHANGES,
CHANGES.txt (from the root of the distribution, not from inside the
package) are actually installed.  If they are, I'd love to know where.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Hey,

On 9/26/07, Fred Drake [EMAIL PROTECTED] wrote:
 On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
  What does one need to tell setup.py to make sure CHANGES.txt is
  available? I understand it isn't by default, then? Hm, it does appear to
  be there by default. I checked grok 0.10's tgz and it's there, and we
  didn't do anything special.

 Do you mean available in the unpacked sdist, or as part of the
 installation?  I don't think any of README, README.txt, CHANGES,
 CHANGES.txt (from the root of the distribution, not from inside the
 package) are actually installed.  If they are, I'd love to know where.

I'm just talking about the sdist. Jim gave me the impression that this
was somehow difficult, but perhaps he meant something else.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:


On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:

What does one need to tell setup.py to make sure CHANGES.txt is
available? I understand it isn't by default, then? Hm, it does  
appear to

be there by default. I checked grok 0.10's tgz and it's there, and we
didn't do anything special.


Do you mean available in the unpacked sdist, or as part of the
installation?  I don't think any of README, README.txt, CHANGES,
CHANGES.txt (from the root of the distribution, not from inside the
package) are actually installed.  If they are, I'd love to know where.


By default READM(.txt) is installed in a source distribution.  
Anything else in the root (aside from setup.py of course and source  
files themselves) aren't without extra setup chants. (These chants  
can be figured out with some effort.  I never remember them, so, if I  
want to do something like this, I have to figure them out again or  
try to find an example with them.)


If we are going to have a change log, which we should, I would prefer  
it to be included in source distributions.  Including a file other  
that README in the root requires extra effort that I don't want to  
require -- writing setup.py files is hard enough as it is.


I'm not crazy about Tres' idea of putting these files in the Python  
packages themselves, but it does have the advantage that it causes  
the files to be included in eggs as well as source distributions.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

Jim Fulton wrote:

On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:


On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:

What does one need to tell setup.py to make sure CHANGES.txt is
available? I understand it isn't by default, then? Hm, it does appear to
be there by default. I checked grok 0.10's tgz and it's there, and we
didn't do anything special.


Do you mean available in the unpacked sdist, or as part of the
installation?  I don't think any of README, README.txt, CHANGES,
CHANGES.txt (from the root of the distribution, not from inside the
package) are actually installed.  If they are, I'd love to know where.


By default READM(.txt) is installed in a source distribution. Anything 
else in the root (aside from setup.py of course and source files 
themselves) aren't without extra setup chants. (These chants can be 
figured out with some effort.  I never remember them, so, if I want to 
do something like this, I have to figure them out again or try to find 
an example with them.)


Actually, no package data is ever included unless you're either

* working from an svn checkout, in which case setuptools will use the 
list of which files are in svn and which aren't as a hint of what to 
include and what not


* creating a MANIFEST.in file to tell setuptools what to include explicitly.


--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 3:32 PM, Philipp von Weitershausen wrote:


Jim Fulton wrote:

On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:

On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:

What does one need to tell setup.py to make sure CHANGES.txt is
available? I understand it isn't by default, then? Hm, it does  
appear to
be there by default. I checked grok 0.10's tgz and it's there,  
and we

didn't do anything special.


Do you mean available in the unpacked sdist, or as part of the
installation?  I don't think any of README, README.txt, CHANGES,
CHANGES.txt (from the root of the distribution, not from inside the
package) are actually installed.  If they are, I'd love to know  
where.
By default READM(.txt) is installed in a source distribution.  
Anything else in the root (aside from setup.py of course and  
source files themselves) aren't without extra setup chants. (These  
chants can be figured out with some effort.  I never remember  
them, so, if I want to do something like this, I have to figure  
them out again or try to find an example with them.)


I was wrong.  Dang.  I think I understand setuptools/distutils and  
I'm proven wrong again. Sheesh.




Actually, no package data is ever included unless you're either

* working from an svn checkout, in which case setuptools will use  
the list of which files are in svn and which aren't as a hint of  
what to include and what not


Certainly, I expect CHANGES.txt to be in svn.  I've just doeble  
checked that files from the root of the package that are checked into  
svn *are* included in sdists.


I retract my objection to CHANGES.txt and offer my apologies.

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Martijn Faassen]

Jim Fulton wrote:


On Sep 26, 2007, at 3:32 PM, Philipp von Weitershausen wrote:

[snip]
* working from an svn checkout, in which case setuptools will use the 
list of which files are in svn and which aren't as a hint of what to 
include and what not


Certainly, I expect CHANGES.txt to be in svn.  I've just doeble checked 
that files from the root of the package that are checked into svn *are* 
included in sdists.


I retract my objection to CHANGES.txt and offer my apologies.


Excellent, we all agree then. :) I did go and check, which is why I was 
so mystified by your statements that it wasn't there.


Regards,

Martijn


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Benji York]

Philipp von Weitershausen wrote:

Stephan Richter wrote:

Because I disagree with that, since you cannot know the next version.


You can always know the minimum version. If you just released 3.4.2, I 
think it's sensible to point the next release to 3.4.3. If you later 
decide that you really need a feature release, you can always bump to 
3.5.0a1 (which would be the first release in the 3.5.x series).


Why not leave the version totally out of the setup.py in the trunk? 
After branching for a release we can set the version (e.g., 1.2), make a 
release, and tag the branch.


We could either leave the version on the branch at the last release or 
continue the trend of mad bumping and have it at the next release 
(which since this is a branch, we can actually predict).


I prefer the last version, but next would work too.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 4:34 PM, Benji York wrote:


Philipp von Weitershausen wrote:

Stephan Richter wrote:
Because I disagree with that, since you cannot know the next  
version.
You can always know the minimum version. If you just released  
3.4.2, I think it's sensible to point the next release to 3.4.3.  
If you later decide that you really need a feature release, you  
can always bump to 3.5.0a1 (which would be the first release in  
the 3.5.x series).


Gary and Benji made me pay attention to this point. :)

I *really* don't like setting the version to the number for the next  
release, since one often doesn't know what it is.



Why not leave the version totally out of the setup.py in the trunk?


Benji and Gary won me over to this point of view. :)

After branching for a release we can set the version (e.g., 1.2),  
make a release, and tag the branch.


We should not require branches.  I would only bother creating  
maintenance branches when they are needed.


Z, B, G, and I propose the following:

- Leave the version # out of setup.py on the trunk and on branches.

When it is time to make a release, either from the trunk or from a  
maint branch:


- Update changes.txt, adding a heading for the new # and date

- Create a tag

- check out or switch to the tag

- Set the version in setup.py on the tag. Check it in.

- Make the release from the tag.

(BTW, when creating maint branches after the fact, the branch should  
be made by copying the trunk at the revision that the first release  
branch for that tag was made, so as not to accidentally get a version  
#.)


I'd prefer not to make an edict, so Benji and Gary will now persuade  
you that this is the best way to go. ;)


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 17:18, Jim Fulton wrote:
 - Update changes.txt, adding a heading for the new # and date

 - Create a tag

 - check out or switch to the tag

 - Set the version in setup.py on the tag. Check it in.

 - Make the release from the tag.

Changing tags is not that good. I'd rather check in a aversion number 
then. ;-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote:


On Wednesday 26 September 2007 17:18, Jim Fulton wrote:

- Update changes.txt, adding a heading for the new # and date

- Create a tag

- check out or switch to the tag

- Set the version in setup.py on the tag. Check it in.

- Make the release from the tag.


Changing tags is not that good. I'd rather check in a aversion number
then. ;-)


This is exactly what we've been doing for Zope 3 releases -- for the  
same reason.  I think it is the one acceptable and reasonable change  
to a tag.  The benefit of forcing us to release from a tag is, imo,  
significant.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 26 Sep 2007, at 23:18 , Jim Fulton wrote:

On Sep 26, 2007, at 4:34 PM, Benji York wrote:


Philipp von Weitershausen wrote:

Stephan Richter wrote:
Because I disagree with that, since you cannot know the next  
version.
You can always know the minimum version. If you just released  
3.4.2, I think it's sensible to point the next release to 3.4.3.  
If you later decide that you really need a feature release, you  
can always bump to 3.5.0a1 (which would be the first release in  
the 3.5.x series).


Gary and Benji made me pay attention to this point. :)

I *really* don't like setting the version to the number for the  
next release, since one often doesn't know what it is.


Maybe. However, when you do the actual release then, you're still  
going to have to find out which version number to use. On release  
branches this is a trivial step, of course: You just look at the  
latest tagged version and increment accordingly. On the trunk it  
might be trickier. After 1.0, do we have 1.1? Or 2.0?


Maye this aspect isn't such a big deal, though.


Why not leave the version totally out of the setup.py in the trunk?


Benji and Gary won me over to this point of view. :)


There's a *really* good reason for putting the upcoming version  
number in setup.py, though: development eggs.


Let's say X depends on Y and I'm developing them simultaneously as  
development eggs in one sandbox (e.g. buildout). I add a feature to Y  
that I'd like to use in X. That means I'll have to change X's version  
dependency regarding Y so that it now depends on Ya.b where a.b is  
the latest release that didn't have the feature I added.


Will Y with the setup.py stating version='unreleased' satisfy the  
Ya.b requirement that X (rightfully) has? If not, then I think we  
have a problem. If yes, then I find that very confusing.


I know that if Y's setup.py stated version='a.b-dev', it will work.  
This what my guide currently suggests (including taking it out just  
for release tags).


After branching for a release we can set the version (e.g., 1.2),  
make a release, and tag the branch.


We should not require branches.  I would only bother creating  
maintenance branches when they are needed.


+1


Z, B, G, and I propose the following:


Who's Z? :)


- Leave the version # out of setup.py on the trunk and on branches.

When it is time to make a release, either from the trunk or from a  
maint branch:


- Update changes.txt, adding a heading for the new # and date

- Create a tag

- check out or switch to the tag

- Set the version in setup.py on the tag. Check it in.

- Make the release from the tag.


I could live with that, even with the fact that you'd be modifying a  
tag, as long as it's done in this exact order and the only  
modificdations to a tag woudl be setting setup.py.


I still see the development egg case the best argument for putting  
the next anticipated version number into setup.py. I think the  
compromise of version number + 'dev' marker would work best.




___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 17:34, Jim Fulton wrote:
 On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote:
  On Wednesday 26 September 2007 17:18, Jim Fulton wrote:
  - Update changes.txt, adding a heading for the new # and date
 
  - Create a tag
 
  - check out or switch to the tag
 
  - Set the version in setup.py on the tag. Check it in.
 
  - Make the release from the tag.
 
  Changing tags is not that good. I'd rather check in a aversion number
  then. ;-)

 This is exactly what we've been doing for Zope 3 releases -- for the  
 same reason.  I think it is the one acceptable and reasonable change  
 to a tag.  The benefit of forcing us to release from a tag is, imo,  
 significant.

Here is a problem that I discussed with Marius earlier today.

I often do not know whether all my setup.py settings are correct until I try 
to upload a release. I frequently get the Development Status classifier 
wrong and I won't be told it is wrong until I try to register the release.

So I usually create the release first and upload it and after that create the 
tag.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 26 Sep 2007, at 22:34 , Benji York wrote:


Philipp von Weitershausen wrote:

Stephan Richter wrote:
Because I disagree with that, since you cannot know the next  
version.
You can always know the minimum version. If you just released  
3.4.2, I think it's sensible to point the next release to 3.4.3.  
If you later decide that you really need a feature release, you  
can always bump to 3.5.0a1 (which would be the first release in  
the 3.5.x series).


Why not leave the version totally out of the setup.py in the trunk?  
After branching for a release we can set the version (e.g., 1.2),  
make a release, and tag the branch.


We could either leave the version on the branch at the last  
release or continue the trend of mad bumping and have it at the  
next release (which since this is a branch, we can actually  
predict).


I prefer the last version, but next would work too.


setuptools suggests setting it to the next version. Apart from the  
fact that it makes more sense to me, the biggest reason I can see is  
the development egg use case. A development egg from the repository  
should have a newer version than the latest released egg.


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 26 Sep 2007, at 23:41 , Stephan Richter wrote:

On Wednesday 26 September 2007 17:34, Jim Fulton wrote:

On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote:

On Wednesday 26 September 2007 17:18, Jim Fulton wrote:

- Update changes.txt, adding a heading for the new # and date

- Create a tag

- check out or switch to the tag

- Set the version in setup.py on the tag. Check it in.

- Make the release from the tag.


Changing tags is not that good. I'd rather check in a aversion  
number

then. ;-)


This is exactly what we've been doing for Zope 3 releases -- for the
same reason.  I think it is the one acceptable and reasonable change
to a tag.  The benefit of forcing us to release from a tag is, imo,
significant.


Here is a problem that I discussed with Marius earlier today.

I often do not know whether all my setup.py settings are correct  
until I try
to upload a release. I frequently get the Development Status  
classifier
wrong and I won't be told it is wrong until I try to register the  
release.


A good way to catch errors before you mess with the CheeseShop is to  
create the egg info and look at it:


  $ python setup.py egg_info
  $ less src/EGG.egg-info/PKG-INFO

So I usually create the release first and upload it and after that  
create the

tag.


Well, you could just as well re-tag when you screwed up. Or just fix  
minor things on the tag and merge them back to the branch.




___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 5:37 PM, Philipp von Weitershausen wrote:


On 26 Sep 2007, at 23:18 , Jim Fulton wrote:

On Sep 26, 2007, at 4:34 PM, Benji York wrote:


Philipp von Weitershausen wrote:

Stephan Richter wrote:
Because I disagree with that, since you cannot know the next  
version.
You can always know the minimum version. If you just released  
3.4.2, I think it's sensible to point the next release to 3.4.3.  
If you later decide that you really need a feature release, you  
can always bump to 3.5.0a1 (which would be the first release in  
the 3.5.x series).


Gary and Benji made me pay attention to this point. :)

I *really* don't like setting the version to the number for the  
next release, since one often doesn't know what it is.


Maybe. However, when you do the actual release then, you're still  
going to have to find out which version number to use. On release  
branches this is a trivial step, of course: You just look at the  
latest tagged version and increment accordingly. On the trunk it  
might be trickier. After 1.0, do we have 1.1? Or 2.0?


Maye this aspect isn't such a big deal, though.


You can always look at the previous tags or at CHANGES.txt.




Why not leave the version totally out of the setup.py in the trunk?


Benji and Gary won me over to this point of view. :)


There's a *really* good reason for putting the upcoming version  
number in setup.py, though: development eggs.


Good point.

Let's say X depends on Y and I'm developing them simultaneously as  
development eggs in one sandbox (e.g. buildout). I add a feature to  
Y that I'd like to use in X. That means I'll have to change X's  
version dependency regarding Y so that it now depends on Ya.b  
where a.b is the latest release that didn't have the feature I added.


Will Y with the setup.py stating version='unreleased' satisfy the  
Ya.b requirement that X (rightfully) has? If not, then I think we  
have a problem. If yes, then I find that very confusing.


Leaving aside for the moment the fact that develop eggs are used  
for system egg installs :(,


I think if a buildout uses a develop egg, there should be a very  
strong presumption that it it should be used. OTOH, if you have a  
part that depends on a previous major version, then you don't really  
want to use a develop egg for the later release.  This is a bit of an  
edge case though.


I know that if Y's setup.py stated version='a.b-dev', it will work.  
This what my guide currently suggests (including taking it out just  
for release tags).


A problem with this is that someone else might make a release of Y,  
either to fix a bug or to add a feature while your working on the new  
feature in Y.


After branching for a release we can set the version (e.g., 1.2),  
make a release, and tag the branch.


We should not require branches.  I would only bother creating  
maintenance branches when they are needed.


+1


Z, B, G, and I propose the following:


Who's Z? :)


- Leave the version # out of setup.py on the trunk and on branches.

When it is time to make a release, either from the trunk or from a  
maint branch:


- Update changes.txt, adding a heading for the new # and date

- Create a tag

- check out or switch to the tag

- Set the version in setup.py on the tag. Check it in.

- Make the release from the tag.


I could live with that, even with the fact that you'd be modifying  
a tag, as long as it's done in this exact order and the only  
modificdations to a tag woudl be setting setup.py.


I still see the development egg case the best argument for putting  
the next anticipated version number into setup.py. I think the  
compromise of version number + 'dev' marker would work best.


I agree that the develop egg case is problematic.  I'd like to think  
about that.


If you ever actually make dev releases, then guessing wrong about the  
next version could cause real problems.  Consider the following case:


We've just released 1.1. We guess the next release is 1.2.  We change  
things and release, 1.2dev-r#. Someone fixes a bug and releases  
1.1.1.  Now there's a dev release of 1.2 that is actually older than  
the 1.1.1 release but that setuptools considers to be newer.  I think  
this is fairly problematic.  Then again, I think that dev releases  
are problematic in a lot of ways.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Philipp von Weitershausen]

On 27 Sep 2007, at 00:14 , Jim Fulton wrote:
Let's say X depends on Y and I'm developing them simultaneously as  
development eggs in one sandbox (e.g. buildout). I add a feature  
to Y that I'd like to use in X. That means I'll have to change X's  
version dependency regarding Y so that it now depends on Ya.b  
where a.b is the latest release that didn't have the feature I added.


Will Y with the setup.py stating version='unreleased' satisfy the  
Ya.b requirement that X (rightfully) has? If not, then I think we  
have a problem. If yes, then I find that very confusing.


Leaving aside for the moment the fact that develop eggs are used  
for system egg installs :(,


I think if a buildout uses a develop egg, there should be a very  
strong presumption that it it should be used. OTOH, if you have a  
part that depends on a previous major version, then you don't  
really want to use a develop egg for the later release.  This is a  
bit of an edge case though.


It is as long as you ignore the fact that all major Linux distros  
install develop eggs into site-packages.


I still see the development egg case the best argument for putting  
the next anticipated version number into setup.py. I think the  
compromise of version number + 'dev' marker would work best.


I agree that the develop egg case is problematic.  I'd like to  
think about that.


If you ever actually make dev releases, then guessing wrong about  
the next version could cause real problems.


Oh, I'm not actually thinking about dev releases. I too think they're  
very problematic. I just suggested using the 'dev' marker as a way to  
tell branches or the trunk apart from tags. On the branches and  
trunk, setup.py's version is the next anticipated release + 'dev',  
while on tags it's just release version. That way people won't  
accidentally make releases from branches or the trunk (because they'd  
get an egg with a 'dev' in the version). They'll have to use a tag.


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: faulty releases and pypi access [update]

[Jim Fulton]

On Sep 26, 2007, at 6:23 PM, Philipp von Weitershausen wrote:


On 27 Sep 2007, at 00:14 , Jim Fulton wrote:
Let's say X depends on Y and I'm developing them simultaneously  
as development eggs in one sandbox (e.g. buildout). I add a  
feature to Y that I'd like to use in X. That means I'll have to  
change X's version dependency regarding Y so that it now depends  
on Ya.b where a.b is the latest release that didn't have the  
feature I added.


Will Y with the setup.py stating version='unreleased' satisfy the  
Ya.b requirement that X (rightfully) has? If not, then I think  
we have a problem. If yes, then I find that very confusing.


Leaving aside for the moment the fact that develop eggs are used  
for system egg installs :(,


I think if a buildout uses a develop egg, there should be a very  
strong presumption that it it should be used. OTOH, if you have a  
part that depends on a previous major version, then you don't  
really want to use a develop egg for the later release.  This is a  
bit of an edge case though.


It is as long as you ignore the fact that all major Linux distros  
install develop eggs into site-packages.


I already left that aside. :)

Buildout should be able to detect this case and deal with it, which  
is why I left it aside.




I still see the development egg case the best argument for  
putting the next anticipated version number into setup.py. I  
think the compromise of version number + 'dev' marker would work  
best.


I agree that the develop egg case is problematic.  I'd like to  
think about that.


If you ever actually make dev releases, then guessing wrong about  
the next version could cause real problems.


Oh, I'm not actually thinking about dev releases. I too think  
they're very problematic. I just suggested using the 'dev' marker  
as a way to tell branches or the trunk apart from tags.


But people will make these releases and leaving the version out will  
mean that these releases will be harmless.


On the branches and trunk, setup.py's version is the next  
anticipated release + 'dev', while on tags it's just release  
version. That way people won't accidentally make releases from  
branches or the trunk (because they'd get an egg with a 'dev' in  
the version). They'll have to use a tag.


You think getting an egg with dev in the version will stop them?

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:
 
 On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
 What does one need to tell setup.py to make sure CHANGES.txt is
 available? I understand it isn't by default, then? Hm, it does  
 appear to
 be there by default. I checked grok 0.10's tgz and it's there, and we
 didn't do anything special.
 Do you mean available in the unpacked sdist, or as part of the
 installation?  I don't think any of README, README.txt, CHANGES,
 CHANGES.txt (from the root of the distribution, not from inside the
 package) are actually installed.  If they are, I'd love to know where.
 
 By default READM(.txt) is installed in a source distribution.  
 Anything else in the root (aside from setup.py of course and source  
 files themselves) aren't without extra setup chants. (These chants  
 can be figured out with some effort.  I never remember them, so, if I  
 want to do something like this, I have to figure them out again or  
 try to find an example with them.)
 
 If we are going to have a change log, which we should, I would prefer  
 it to be included in source distributions.

I want them present in the *installed* egg, not just in the source
distribution:  setuptools doesn't preserve source distributions after
creating / installing the '.egg' version.

  Including a file other  
 that README in the root requires extra effort that I don't want to  
 require -- writing setup.py files is hard enough as it is.

Put the real README.txt and CHANGES.txt in the actual package:  the
version which is a peer of 'setup.py' should be a stub which points to
the real versions.

 I'm not crazy about Tres' idea of putting these files in the Python  
 packages themselves, but it does have the advantage that it causes  
 the files to be included in eggs as well as source distributions.

Not having those files available after installing is a complete
non-starter for me.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+viq+gerLs4ltQ4RAtNfAJ9jNe3abDAUpCP/0a7Dy+Zc0XI25QCgxwgp
QDrrR4nwci92k2diKxMvmQc=
=upXO
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
 Jim Fulton wrote:
 On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:

 On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
 What does one need to tell setup.py to make sure CHANGES.txt is
 available? I understand it isn't by default, then? Hm, it does appear to
 be there by default. I checked grok 0.10's tgz and it's there, and we
 didn't do anything special.
 Do you mean available in the unpacked sdist, or as part of the
 installation?  I don't think any of README, README.txt, CHANGES,
 CHANGES.txt (from the root of the distribution, not from inside the
 package) are actually installed.  If they are, I'd love to know where.
 By default READM(.txt) is installed in a source distribution. Anything 
 else in the root (aside from setup.py of course and source files 
 themselves) aren't without extra setup chants. (These chants can be 
 figured out with some effort.  I never remember them, so, if I want to 
 do something like this, I have to figure them out again or try to find 
 an example with them.)
 
 Actually, no package data is ever included unless you're either
 
 * working from an svn checkout, in which case setuptools will use the 
 list of which files are in svn and which aren't as a hint of what to 
 include and what not
 
 * creating a MANIFEST.in file to tell setuptools what to include explicitly.

or you write your own package finder.  Frankly, anybody who is making
package releases from anything other than a versino-controlled checkout
is insane.

Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.

I'm *not* kidding about that:  taking shortcuts durng the release
process transfers pain / cost to everyone downstream.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+vll+gerLs4ltQ4RAh0NAKCKZCn7wcd3tgqghK92MfA7WKwkxQCgrTo6
78QLmHGfbMy1oBOrQy+i3k0=
=wtNc
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benji York wrote:
 Philipp von Weitershausen wrote:
 Stephan Richter wrote:
 Because I disagree with that, since you cannot know the next version.
 You can always know the minimum version. If you just released 3.4.2, I 
 think it's sensible to point the next release to 3.4.3. If you later 
 decide that you really need a feature release, you can always bump to 
 3.5.0a1 (which would be the first release in the 3.5.x series).
 
 Why not leave the version totally out of the setup.py in the trunk? 
 After branching for a release we can set the version (e.g., 1.2), make a 
 release, and tag the branch.
 
 We could either leave the version on the branch at the last release or 
 continue the trend of mad bumping and have it at the next release 
 (which since this is a branch, we can actually predict).
 
 I prefer the last version, but next would work too.

I prefer neither, as I don't want to encourage people to make releases
without doing the bookkeeping required to get the versions right.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+vm++gerLs4ltQ4RApbhAJ9Anxm8SDCG+b0pk6MbpPT/cqaWTgCfYebK
drwMpQGfEvPMyT7x5nLAwYg=
=1BCs
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Wednesday 26 September 2007 17:34, Jim Fulton wrote:
 On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote:
 On Wednesday 26 September 2007 17:18, Jim Fulton wrote:
 - Update changes.txt, adding a heading for the new # and date

 - Create a tag

 - check out or switch to the tag

 - Set the version in setup.py on the tag. Check it in.

 - Make the release from the tag.
 Changing tags is not that good. I'd rather check in a aversion number
 then. ;-)
 This is exactly what we've been doing for Zope 3 releases -- for the  
 same reason.  I think it is the one acceptable and reasonable change  
 to a tag.  The benefit of forcing us to release from a tag is, imo,  
 significant.
 
 Here is a problem that I discussed with Marius earlier today.
 
 I often do not know whether all my setup.py settings are correct until I try 
 to upload a release.

You should *never* be uploading a release that you don't already *know*
is correct.

 I frequently get the Development Status classifier
 wrong and I won't be told it is wrong until I try to register the release.

If you are using 'setup.py register upload' to do your checking, you
need a better tool:  the consequences of carelessness are too
significant (bad releases punish everyone *else*).

 So I usually create the release first and upload it and after that create the 
 tag.

- -100.  Get it right, check it in, *then* upload the distribution.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+vrc+gerLs4ltQ4RAj1gAJ4pODs1F2kHFNDHS7JWNOFcQ0k8lACg0Szp
q7CgaDorr2xdLLPtp+N90VM=
=8P1J
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
 On 26 Sep 2007, at 23:18 , Jim Fulton wrote:
 On Sep 26, 2007, at 4:34 PM, Benji York wrote:

 Philipp von Weitershausen wrote:
 Stephan Richter wrote:
 Because I disagree with that, since you cannot know the next  
 version.
 You can always know the minimum version. If you just released  
 3.4.2, I think it's sensible to point the next release to 3.4.3.  
 If you later decide that you really need a feature release, you  
 can always bump to 3.5.0a1 (which would be the first release in  
 the 3.5.x series).
 Gary and Benji made me pay attention to this point. :)

 I *really* don't like setting the version to the number for the  
 next release, since one often doesn't know what it is.
 
 Maybe. However, when you do the actual release then, you're still  
 going to have to find out which version number to use. On release  
 branches this is a trivial step, of course: You just look at the  
 latest tagged version and increment accordingly. On the trunk it  
 might be trickier. After 1.0, do we have 1.1? Or 2.0?
 
 Maye this aspect isn't such a big deal, though.
 
 Why not leave the version totally out of the setup.py in the trunk?
 Benji and Gary won me over to this point of view. :)
 
 There's a *really* good reason for putting the upcoming version  
 number in setup.py, though: development eggs.

- -100.  'development eggs' which get released into the wild are an
abomination of desolation, and should be avoided at *any* cost. (I'm
assuming that you mean eggs / distributions which get uploaded to some
package repository, rather than being installed via 'setup.py develop').

 Let's say X depends on Y and I'm developing them simultaneously as  
 development eggs in one sandbox (e.g. buildout). I add a feature to Y  
 that I'd like to use in X. That means I'll have to change X's version  
 dependency regarding Y so that it now depends on Ya.b where a.b is  
 the latest release that didn't have the feature I added.

Logically speaking, you *can't* release Y with the new requirement until
*after* a release of X is availabe with the required feature:  while
they are both in development, hacking on Y's 'install_requires' is
pointless.

Once X is released with the new feature, *then* you can update the
develpoment egg for 'Y' to mandate that version of 'X':  at that point,
you should be removing the development egg of 'X', in order to verify
that 'Y' works with an installable 'X'.

 Will Y with the setup.py stating version='unreleased' satisfy the  
 Ya.b requirement that X (rightfully) has? If not, then I think we  
 have a problem. If yes, then I find that very confusing.

'Y' can't be changed simultaneously with 'X':  that is the nature of
dependency management.

 I know that if Y's setup.py stated version='a.b-dev', it will work.  
 This what my guide currently suggests (including taking it out just  
 for release tags).

I would *never* check in a release of 'Y' which mandated a non-released
version of 'X'.

 After branching for a release we can set the version (e.g., 1.2),  
 make a release, and tag the branch.
 We should not require branches.  I would only bother creating  
 maintenance branches when they are needed.
 
 +1

Agreed.  Creating a release branch in SVN from a tag is trivial, and
therefore shouldn't be required ahead of time.


 Z, B, G, and I propose the following:
 
 Who's Z? :)
 
 - Leave the version # out of setup.py on the trunk and on branches.

 When it is time to make a release, either from the trunk or from a  
 maint branch:

 - Update changes.txt, adding a heading for the new # and date

 - Create a tag

 - check out or switch to the tag

 - Set the version in setup.py on the tag. Check it in.

 - Make the release from the tag.
 
 I could live with that, even with the fact that you'd be modifying a  
 tag, as long as it's done in this exact order and the only  
 modificdations to a tag woudl be setting setup.py.

I'm fine with making packaging only changes to a tag.

 I still see the development egg case the best argument for putting  
 the next anticipated version number into setup.py. I think the  
 compromise of version number + 'dev' marker would work best.

I'd rather have no version number at all.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+vy1+gerLs4ltQ4RAv9TAKDR4/phUYakFY4WI0RgW1QN6QgQTgCeMBd2
BOy03oWEARIta+ye2AB5wPs=
=PaEC
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
 On 26 Sep 2007, at 22:34 , Benji York wrote:
 
 Philipp von Weitershausen wrote:
 Stephan Richter wrote:
 Because I disagree with that, since you cannot know the next  
 version.
 You can always know the minimum version. If you just released  
 3.4.2, I think it's sensible to point the next release to 3.4.3.  
 If you later decide that you really need a feature release, you  
 can always bump to 3.5.0a1 (which would be the first release in  
 the 3.5.x series).
 Why not leave the version totally out of the setup.py in the trunk?  
 After branching for a release we can set the version (e.g., 1.2),  
 make a release, and tag the branch.

 We could either leave the version on the branch at the last  
 release or continue the trend of mad bumping and have it at the  
 next release (which since this is a branch, we can actually  
 predict).

 I prefer the last version, but next would work too.
 
 setuptools suggests setting it to the next version. Apart from the  
 fact that it makes more sense to me, the biggest reason I can see is  
 the development egg use case. A development egg from the repository  
 should have a newer version than the latest released egg.

If it were impossible to create an 'sdist' or 'bdist_egg' from such a
checkout, I would be OK with this.  However, history shows that people
*will* make distributions from such not-ready-for-prime-time
checkouts, at which point the damage is orders of magnitude bigger than
any value derived from convenience in installing the 'develop' egg.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+v44+gerLs4ltQ4RAkc9AJ9I1GobzNfnIJdtM0BgAUV5TDeVhwCffe5S
m86ebz0mOlkA75MSZ+goGus=
=x3mI
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: faulty releases and pypi access [update]

[Stephan Richter]

On Wednesday 26 September 2007 20:35, Tres Seaver wrote:
  So I usually create the release first and upload it and after that create
  the tag.

 -100.  Get it right, check it in, *then* upload the distribution.

We do not have the tools. There is simply no telling beforehand. Marius and I 
worked on the ideas of a  tool that he proposed earlier today.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com