HOWTO for maintainers?

Dev
1

I’m planning on writing a HOWTO for maintainers. Primarily to document the release process which is somewhat complicated. Do you have any suggestions for naming such a file or if it should be part of the README.md? Maybe HOWTO.md is too general and would attract the wrong audience?

1 Like
2

DEVELOPERS.md or “Developer’s Guide” (as separate from User’s Guide) or DEVELOPING.md are common.

I was just thinking recently it would be good to gather the repos, docker locations, forum setup, and download distributions sites (www2.graphviz.org).

2 Likes
3

Taken! With gather; do you mean to document them in such a file?

4

Yeah, I figured that such things would be good to document in a file (or wiki, or whatever, I’m not picky - version controlled files are my preference).

1 Like
5

On June 1, 2018, I asked John Ellson how to make a new stable version, and his response was this. I was still following this instruction recently. Maybe there is a better way.

  1. Update Changelog and change the version number in autogen.sh to the stable release number. commit to git.
  2. Run the build scripts with “ARCHIVE” as a parameter so the the results get stored in the separate stable tree. This bit I have to do on the the host that schedules all the builds, which is still in AT&T.
  3. After the stable build has completed. Re-edit autogen.sh to start the next development series, and commit to git.

We do not have any connections more to AT&T, so I doubt Step 2 is current.

6

I have more up-to-date instructions that work. Stay tuned

7

MR: Add DEVELOPERS.md with release instructions (!1401) · Merge requests · graphviz / graphviz · GitLab

I’m thinking that I’m going to do the next release and see if I can follow my own instructions and then update the guide and let someone else try it to the release after that.

8

This is available at

https://gitlab.com/graphviz/graphviz/-/blob/master/DEVELOPERS.md

since a while back.

9

Now that I’m in the middle of doing the new 2.44.1 patch release I’ve decided not to follow the release instructions in that I’m going to do this a any normal merge request because it’s much safer and the commit history in master will have less clutter in the form of manual mistakes made during the process.

If there are no objections to this I will update the release instructions accordingly.

10

SGTM (I like running CI for all the commits)

1 Like
11

I also skipped the stage of creating and pushing a stable_release_2.44.1 tag and went directly on the create a release with the 2.44.1 tag.

Is there some upstream tool that requires the stable_release_2.44.1 tag to exist?