ReleaseProcedure is flawed

[Jari Häkkinen]

In patch release procedure step 1.iv assumes that two more check-ins are always required. Well, it is not and therefore the procedure must be rewritten. The problem is that step 2 does not always initiate a commit.

[Jari Häkkinen]

I was forced to make an extra commit (changeset:459) to avoid problems in source:branches/0.6-stable/ChangeLog​.

[Peter Johansson]

Is this really true :)

I remember I chose this "+2" because it is pretty robust. Either you will have two more commits and (obviously) works. Or you will have only one commit. Then revision+2 is the revision of the tag, which implies the Changelog anchor works (I guess). I realize right now the might be a problem that Trac complains about the revision does not exist in branch. But if Trac is that very sensitive I presume you would have added that information.

[Jari Häkkinen]

Well, trac is sensitive about these issues.

[Peter Johansson]

Ok, a possible solution could be to flip some order. First doing the copyright update, and then do the update in ChangeLog? and NEWS. The bad thing is that the update of ChangeLog? and NEWS will not be included in the copyright update. One could however take care of this manually (when it is needed).

I am not too happy about that solution because it involves some manual work, and the objective must be to remove these sources for mistakes.

[Peter Johansson]

Replying to jari:

Well, trac is sensitive about these issues.

I tried ​http://trac.thep.lu.se/trac/svndigest/log/branches/0.6-stable?rev=460&stop_rev=438 and also ​http://trac.thep.lu.se/trac/svndigest/log/branches/0.6-stable?rev=459&stop_rev=438

They give the same result, so I don't understand your statement above. In what sense is Trac sensitive about these issues?

[Jari Häkkinen]

In your case rev 460 do exist in the repository. In my case it did not since no one had committed 460 when I made my tests.

[Peter Johansson]

Sure, so the problem is that we cannot test the link in the file since the link goes to a revision that does not exist. However, next step in procedure is to make a tag and after that is done the revision exists, and the problem is gone. So this problem is less severe than the impression you gave initially.

[Jari Häkkinen]

Hm, style is everything.

[Peter Johansson]

I think it's more severe that the procedure always give conflicts. NEWS, and Changelog always end up in conflict when merging stable-branch into trunk. Even worse is that changes of PATCH VERSION in version.m4 is merged into trunk, which obviously is wrong.

The subversion team announce dramatically improved merge support in v1.5, which is beta testing at time of writing this. Should be out soon. We should look how we can improve this issues when having svn 1.5 at hand.

[Peter Johansson]

Subversion itself has a model that solves these issues. They implement everything in trunk and then merge it into stable-branch. The only thing they change in stable-branch directly is version numbers, which are irrelevant to the trunk. There is no merge back to the trunk from the branch.

I am not sure I like this model. I think I prefer fixing bugs in the branch, because you wanna fix the bug in the context it occurred (i.e. without all extra development existing in trunk). One could of course accomplish that by using a couple of svn switch but I think that would get way too complicated.

[Jari Häkkinen]

Replying to peter:

I am not sure I like this model. I think I prefer fixing bugs in the branch, because you wanna fix the bug in the context it occurred (i.e. without all extra development existing in trunk). One could of course accomplish that by using a couple of svn switch but I think that would get way too complicated.

I agree, fixing bugs in the trunk and then merge into the stable branch seems to be complicated.

[Peter Johansson]

Subversion provides a script, gnuify-changelog.pl, that transforms svn log -v to something that looks like GNU Changelog. For instance, issue svn log -v in current trunk yields:

------------------------------------------------------------------------
r671 | peter | 2008-07-04 08:02:17 -0400 (Fri, 04 Jul 2008) | 1 line
Changed paths:
   M /trunk/README

removed text about staticbin in README
------------------------------------------------------------------------
r670 | jari | 2008-07-03 20:15:16 -0400 (Thu, 03 Jul 2008) | 1 line
Changed paths:
   M /trunk/configure.ac

Fixing indentation.

and if I filter with gnuify_changelog.pl I get

2008-07-04  peter
        Changed paths:
           M /trunk/README

        removed text about staticbin in README

2008-07-03  jari
        Changed paths:
           M /trunk/configure.ac

        Fixing indentation.

One idea would be to not have any Changelog in the repository, but create it at release time. In that way the whole issue with calculating the tag revision would vanish...

[Peter Johansson]

also see discussion in ​yat

[Peter Johansson]

I'll copy the RP in yat.

[Peter Johansson]

(In [811]) refs #257

[Peter Johansson]

Everything is done except that we should update patch release so we use make release there too. That is, however, not available in 0.6.x, so we should wait with that update until we know there will be no more releases in 0.6.x.