Timeline for releasing Graphviz 2.44.2

We’ve accrued enough changes, fixes etc since the last release that I think we should start thinking about cutting a new one.

@magjac, you’ve been making a lot of changes on the Windows side and I think we should time this so the next release lines up with the Windows build being at some reasonable milestone. I.e. we shouldn’t pick a commit to release that has part 1 of some larger Windows change, but not parts 2 etc. I’ll defer to you for timing.

Great idea. I’ve been thinking along those lines myself. I would like to have https://gitlab.com/graphviz/graphviz/-/merge_requests/1569 before the release since many of my latest MRs are also steps towards this one.

Should we do 2.44.2 or 2.45.0? The re-add of lefty and gvedit to Windows could be considered both bug fixes or functional additions depending on which time perspective you take. Also the removal of the need to run dot -c could be in both categories depending on what’s been stated about it in the past.

I’m totally open and fine with either. I just wanted it to be discussed.

Ah right, I was not thinking about semantic versioning. You’re right, we should go to 2.45.0.

1 Like

So we used to supposedly use even numbers like 2.44 for “stable” releases and odd numbers like 2.45 for the following “development” releases, but I use scare quotes because typically we did development in private copies, and almost all the time, the development releases were actually better. I’m not sure if this is something other projects do, and if it matters.

I’ve never encountered this “on”/“off” versioning scheme elsewhere. What differentiated a development release from a stable release? Did a stable release get more testing/validation prior to release?

With the present maturity of version control systems, I don’t think we need a development release. This class of users can worship the “live at head” mantra and run a build of the latest tip of master.

We mostly left the even-numbered releases alone and only updated them rarely by back-porting changes if they were really important, e.g. fixed a security problem or something particularly stupid.

Huh? You backported (less discriminately) to development releases? Who was tracking development releases and could not upgrade or use stable but also wanted cherry-picked patches? Sorry, I think I just don’t understand the user model.

We abandoned the even/odd versioning scheme when we adopted semantic versioning since it’s incompatible with semantic versioning. See the discussion in Version numbering going forward? where this SO post is referenced:

We no longer have any currently open “release-blocker” labelled issues. I’ve marked MR !1648 as blocking because it fixes a regression. Other than that, it looks like we’re clear to cut a new release.

I wanted to get some consensus that others feel the same way. Are we in a position to do this? Or are there other release-blocking issues that haven’t yet been labelled as such?

I concur. :scissors:

I changed my mind. I tagged also MR !1649 which depends on MR !1648.

There’s nothing I’m aware of blocking release

Excellent. I think the next release will likely be the last before we migrate to C99 and C++11. I doubt this will cause any significant problems, but something to keep in mind when we announce the release to users.

The two above MRs are now merged. AFAIK we’re now clear to release.

Looking at the changelog, this is going to be a pretty massive release in terms of the delta since the last one. I suggest we focus on getting this out the door before landing further changes.

@magjac, you’re essentially our release manager at this point. Please let us know if there’s anything we can do to help. Obviously I can slow/stall the pace of my MR submissions.

I’m happy to do the release, but also open for letting anyone else do it by trying to follow my instructions in

1 Like

Once its tagged I will kick off the wasm build (sounds like I might need some tweaks to my cmake files?)

1 Like

Suggestion - add a link to this site in the main readme.md docs?

I’m still not confident of following the release procedure correctly myself. Given the large churn in this release, I don’t think it’s a good candidate guinea pig to try this experiment. I’d like a couple of smooth, uneventful releases if possible before changing things up too much.

In future I’d like to further automate/script the release process to make it bulletproof. Bonus points if we could have a CI task observe a release git tag and package the release itself.

OK, I can do it this weekend.

1 Like

I just realized that we have already had development versions 2.45… out. I think the last one was 2.45.20200729.1351 deployed in

I think that forces us to go to 2.46.0.