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.
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
-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
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*
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
-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
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
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
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)
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
-
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
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
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
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
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
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
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
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
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]
-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
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
-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
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
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
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
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
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
-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
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.
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
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
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
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
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
-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
-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
-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
-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
-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
-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
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
69 matches
Mail list logo
