[python-committers] Cutting Python 2.6

[Anthony Baxter]

On Fri, Oct 3, 2008 at 7:06 AM, Nicholas Bastin <nick.bastin at gmail.com> wrote:
>
>
> On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <martin at v.loewis.de>
> wrote:
>>
>> > You always create a branch for the release (subversion doesn't make any
>> > distinction between a tag and a branch anyhow, so you might as well just
>> > make a branch).
>>
>> I don't think the tag should be edited (there are a few that were, and
>> that's unfortunate already). For example, conversion to bzr will
>> conclude it's a bazaar branch, not a tag.
>
> I agree, that's why I think we should make a branch.  Tags should be treated
> as immutable - it's merely an artifact of a limitation in the source control
> system we use that you can't make real labels.
>
>>
>> It's standard procedure to change the code after declaring it
>> releasable; during the release process, the version numbers get adjusted
>> throughout, and those changes get committed before the release tag is
>> made.
>
> I guess my question is, is there a normal use case where the code needs to
> be changed for a release after the 'tag' is made? If all the changes are
> getting committed before the release tag is made, then what is the problem?

It's happened a couple of times when I've made releases - the process
I had was to automate it as much as possible, then take the generated
tarball, unpack it freshly and run the full tests, and then check
things like the README and all those other places. Making a release is
still a pretty fiddly process, and things slip through.