On Jun 18, 2008, at 20:30 , yuppie wrote:
The current Zope 2 policy doesn't make sure the change history of
unreleased versions is complete. But that's no essential part of
that policy. And working with unreleased versions you might use
subversion anyway.
See, I think that's bad. The
Hi,
On Wed, Jun 18, 2008 at 11:09:17PM +0200, Martijn Faassen wrote:
[...]
If I know I normally only have to check the bottom (or top) of each
section to see whether something got added since last time I checked,
there's less chance I'll miss it and make a mistake.
It's not a major point,
On Jun 19, 2008, at 09:51 , Christian Theune wrote:
On Thu, Jun 19, 2008 at 09:08:54AM +0200, Jens Vagelpohl wrote:
See, I think that's bad. The change log should reflect all changes,
be
it in a released version or from Subversion. Or be it a release
branch
or the trunk.
Please note
Hi!
Second try. My first response to this lead to a discussion about
immediate or delayed syncing of CHANGES.txt. That was not my point.
Christian Theune wrote:
On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote:
On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles [EMAIL
On Jun 19, 2008, at 12:32 , yuppie wrote:
There is always *one* well defined current maintenance branch.
Version numbering *does* imply a time line if you ignore old
maintenance branches. It's not hard at all to get this right.
I don't think that assumption holds true. Again, using the
Jens Vagelpohl wrote:
On Jun 19, 2008, at 12:32 , yuppie wrote:
There is always *one* well defined current maintenance branch. Version
numbering *does* imply a time line if you ignore old maintenance
branches. It's not hard at all to get this right.
I don't think that assumption holds true.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
Hi,
On Wed, Jun 18, 2008 at 11:09:17PM +0200, Martijn Faassen wrote:
[...]
If I know I normally only have to check the bottom (or top) of each
section to see whether something got added since last time I checked,
On Jun 19, 2008, at 13:36 , yuppie wrote:
Jens Vagelpohl wrote:
On Jun 19, 2008, at 12:32 , yuppie wrote:
There is always *one* well defined current maintenance branch.
Version numbering *does* imply a time line if you ignore old
maintenance branches. It's not hard at all to get this
Tres Seaver wrote:
Christian Theune wrote:
[snip]
My preference would be to have more important changes first.
Please don't make it a judgement call: keep it time-descending order,
just like the releases. Among other things, this makes merge conflicts
more obvious, and easier to to fix.
On Jun 19, 2008, at 14:41 , Martijn Faassen wrote:
Tres Seaver wrote:
Christian Theune wrote:
[snip]
My preference would be to have more important changes first.
Please don't make it a judgement call: keep it time-descending
order,
just like the releases. Among other things, this makes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Tres Seaver wrote:
Christian Theune wrote:
[snip]
My preference would be to have more important changes first.
Please don't make it a judgement call: keep it time-descending order,
just like the releases. Among other
Jens Vagelpohl wrote:
On Jun 19, 2008, at 13:36 , yuppie wrote:
Jens Vagelpohl wrote:
On Jun 19, 2008, at 12:32 , yuppie wrote:
There is always *one* well defined current maintenance branch.
Version numbering *does* imply a time line if you ignore old
maintenance branches. It's not hard at
Hi!
Christian Theune wrote:
On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote:
On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles [EMAIL PROTECTED]
wrote:
The risk is that people will think the bug is fixed in 3.6.0 and not in the
3.5 branch.
That's a general documentation
On Jun 18, 2008, at 19:00 , yuppie wrote:
Why do we maintain a CHANGES.txt file? Who reads it and why?
The audience I have in mind are users of released versions. They
read CHANGES.txt to figure out what's new in a release.
Let's take Zope 2 as an example:
Most people will currently use
Jens Vagelpohl wrote:
On Jun 18, 2008, at 19:00 , yuppie wrote:
Why do we maintain a CHANGES.txt file? Who reads it and why?
The audience I have in mind are users of released versions. They read
CHANGES.txt to figure out what's new in a release.
Let's take Zope 2 as an example:
Most
On Wed, Jun 18, 2008 at 1:27 PM, yuppie [EMAIL PROTECTED] wrote:
Sorry. I was referring to the current Zope 2 (and CMF) policy:
Note that you don't need to note the fix in the CHANGES.txt on the trunk if
you don't want to. At the time a new feature release is made, we merge the
items in
On Jun 18, 2008, at 19:27 , yuppie wrote:
That's not the only audience. I as a developer consult CHANGES.txt
to (hopefully) find *all* changes on the respective branch or on
the trunk that have flowed into it until now.
Can't developers use the subversion history?
It's much quicker to
On Jun 18, 2008, at 19:32 , Fred Drake wrote:
On Wed, Jun 18, 2008 at 1:27 PM, yuppie [EMAIL PROTECTED]
wrote:
Sorry. I was referring to the current Zope 2 (and CMF) policy:
Note that you don't need to note the fix in the CHANGES.txt on the
trunk if
you don't want to. At the time a new
Hi!
Jens Vagelpohl wrote:
On Jun 18, 2008, at 19:27 , yuppie wrote:
That's not the only audience. I as a developer consult CHANGES.txt to
(hopefully) find *all* changes on the respective branch or on the
trunk that have flowed into it until now.
Can't developers use the subversion history?
Hi there,
Christian Theune wrote:
[snip]
This results in the following properties for the CHANGES.txt:
- The trunk will contain sections for feature releases (e.g. 1.0, 1.1, ..) but
not bugfix releases (e.g. 1.0.2).
- Bug fixes will appear once in the feature release of the trunk (e.g. 1.1)
On Wed, Jun 18, 2008 at 10:38:51PM +0200, Martijn Faassen wrote:
And then I add a feature 'Kwack' or fix a bug 'Dag', where do I add
them? To the top of the sections or to the bottom? I've noticed people
do different things there, which sometimes leads to confusion (I might
look at the
Hi there,
On Wed, Jun 18, 2008 at 11:02 PM, Christian Theune [EMAIL PROTECTED] wrote:
[snip]
I do not consider stuff within a version do be ordered by a given criterion,
except maybe readability, so during development I tend to add stuff to the
top, because it's easier to reach. Sometimes I
22 matches
Mail list logo
