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: