Opened 14 years ago

Closed 11 years ago

#257 closed defect (fixed)

ReleaseProcedure is flawed

Reported by: Jari Häkkinen Owned by: Peter Johansson
Priority: major Milestone: svndigest 0.7
Component: documentation Version: trunk
Keywords: Cc:

Description

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.

Change History (18)

comment:1 Changed 14 years ago by Jari Häkkinen

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

comment:2 Changed 14 years ago by 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.

comment:3 Changed 14 years ago by Jari Häkkinen

Well, trac is sensitive about these issues.

comment:4 Changed 14 years ago by 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.

comment:5 in reply to:  3 Changed 14 years ago by 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?

comment:6 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by 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.

comment:8 Changed 14 years ago by Jari Häkkinen

Hm, style is everything.

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by 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.

comment:11 in reply to:  10 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by 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...

comment:13 Changed 12 years ago by Peter Johansson

also see discussion in yat

comment:14 Changed 12 years ago by Peter Johansson

Owner: changed from Jari Häkkinen to Peter Johansson
Status: newassigned

I'll copy the RP in yat.

comment:15 Changed 12 years ago by Peter Johansson

(In [811]) refs #257

comment:16 Changed 12 years ago by Peter Johansson

Status: assignednew

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.

comment:17 Changed 11 years ago by Peter Johansson

Status: newassigned

comment:18 Changed 11 years ago by Peter Johansson

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.