Is it possible with svn or hg to get a list of the commits that changed
version x to version y?
A regular "svn log" on the maintenance branch will give you all the
changes. You'll recognize from the checkin messages when the previous
release was.
Would is not be possible to get a diff betwe
On 5/28/2010 11:41 PM, Nick Coghlan wrote:
However, it may be worth modifying the policy to ensure that such
exceptional bug fixes be mentioned prominently in the release notes and
on the download page for that maintenance release.
A sentence like "The behavior of it.X.truncate has been intent
On 5/29/2010 6:39 AM, Antoine Pitrou wrote:
It is not the product of oversight.
I am actually glad, in a sense, that it was not casual whim. ;-)
I do not like the change, since it moves streams back further away from
Python's sequence model, but I withdraw the request for reversion in 3.1.3.
On Fri, 28 May 2010 20:31:02 -0400
Steve Holden wrote:
> I think it shows how developers can "get worked over" if they are
> insufficiently vigilant.
>
> 1) I completely agree, and adduce as evidence the fact that something
> like this always seems to happen when the rule is broken;
Well it's tr
On 29/05/10 09:03, Terry Reedy wrote:
After filing
http://bugs.python.org/issue8840
I was rather shocked to be told that the code-breaking and
policy-violating change was intentional because being 'more consistent
with other file-handling APIs out there' was somehow more important than
consistenc
On 29/05/10 09:03, Terry Reedy wrote:
After filing
http://bugs.python.org/issue8840
I was rather shocked to be told that the code-breaking and
policy-violating change was intentional because being 'more consistent
with other file-handling APIs out there' was somehow more important than
consistenc
2010/5/28 Steve Holden :
> Terry Reedy wrote:
>> http://bugs.python.org/issue8840
>> I was rather shocked to be told that the code-breaking and
>> policy-violating change was intentional because being 'more consistent
>> with other file-handling APIs out there' was somehow more important than
>> co
Terry Reedy wrote:
> I had the strong impression that there was a policy that x.y.z bugfix
> releases should only fix bugs and not add new features and revise
> current ones. The rationale, as I understood it, is that x.y.z releases
> should be increasingly better implementations of a stable x.y fe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
> I had the strong impression that there was a policy that x.y.z bugfix
> releases should only fix bugs and not add new features and revise
> current ones. The rationale, as I understood it, is that x.y.z releases
> should be incr
I had the strong impression that there was a policy that x.y.z bugfix
releases should only fix bugs and not add new features and revise
current ones. The rationale, as I understood it, is that x.y.z releases
should be increasingly better implementations of a stable x.y feature
set. Adding featu
10 matches
Mail list logo
