Re: Release process, syncing with Emacs

[Michael Albinus]

Kai Grossjohann <address@hidden> writes:

> Currently, there are a stable branch and the trunk where new
> development happens.  I also decided that I would like to keep Emacs
> in sync with the stable branch.  (Likewise for XEmacs, where I have
> invested too little, aka zero, work recently.)
>
> I thought that every stable (2.0.x) release of Tramp would be moved
> into Emacs, and every Tramp change from Emacs would be incorporated
> into the trunk and stable branches.
>
> But then it turns out that little patches went into Emacs between
> 2.0.x releases.  Not good.  Luckily, I only got one reject on the
> last merge.

I don't see a general problem here. It happened twice because of
problems detected in Emacs pre-release tests since Emacs has been
frozen beginning of May.

The crucial point is that such changes should go into tramp-stable the
same time, not only into the trunk (I believe it didn't happen for the
tramp-locked patch at least; I cannot check it just now). The only
problem might be stability. But usually, a stable Tramp release should
appear earliest after 1 or 2 weeks of the last change in CVS, in order
to see whether it works.

But there is another prblem: there should be a policy what to do with
bug fixes applied to the trunk. Either to apply it to tramp-stable CVS
in parallel (this didn't happen last time), or to merge such small
fixes from trunk into tramp-stable before releasing a Tramp 2.0.x
(this didn't happen either for Tramp 2.0.42, I believe). The second
policy is still possible, because the trunk is not SO different from
tramp-stable until now; but this will change. So I'm in favor of the
"apply it twice" policy.

> The other thing I wanted to talk about was the fact that release
> entries need to be made in the ChangeLog files.  But I think those
> ChangeLog entries could be done automatically.  Perhaps I can write a
> Makefile target for them.

Honestly, I'm lost. What's the problem in writing release entries into
ChangeLog?

> Kai

Best regards, Michael.