Sublime Forum

How SublimeText changelog is generated behind the curtains?

#1

I’ve always been curious about how SublimeText changelogs are generated behind the curtains, if you feel like it, could you please explain a little bit about the process/tools used behind the curtains?

There are bazillion tools out there to generate changelogs automatically but mostly of them based on semver. I find it pretty convenient & cozy the method used by sublime by using the so called build numbers. My instinct tells me these ST changelogs are somehow generated automatically out of version control’s history rather than manually but who knows, I’d definitely like to know more about the process itself :slight_smile:

Thanks in advance!

0 Likes

#2

Nope, they’re pretty much just manual.

1 Like

#3

Oh, I see… :open_mouth: What about the build numbers, what’s the criterion behind those? Are they generated out of semver tags?

0 Likes

#4

If you look in the application directory, there is a changelog.txt file which contains some basic HTML describing the changelog. I think ST just renders that in a window.

0 Likes

#5

Build numbers are just incremental, though the first number represents the major version.

0 Likes

#6

Ok, yeah, it’s clear the first number represents the major version but what do you mean by “are just incremental”? ie:

3.2.2 (Build 3211) has a changeset of 5 items
3.2.1 (Build 3207) has a changeset of 16 items

3211-3207 != 5+16

:slight_smile: … So yeah, not very obvious the system used here but interesting nevertheless, reason of my question is because I was exploring some nice system to create changelogs and sublime’s definitely caught my attention.

As I said at the beginning of the thread, it seems there are hundreds of tools out there (like auto-changelog) but many of them are just “too sophisticated” :confused:

0 Likes

#7

The number of times the build increments has nothing to do with the number of changes (except coincidentally); the build number increments when they release a build to the public, not to indicate that a specific bug/feature has been included, or per commit, etc.

Imagine that there’s a build server set up where you can click a button, and it checks out all of the code and builds a version of it for Windows (32 and 64 bit), Linux (32 and 64 bit) and MacOS (64 bit), bundles everything together, and files drop out the other side to be downloaded as zip files, linux packages, etc.

Now imagine that the first thing that happens when you click the button is that the stored build number is incremented by 1 in the code, to mark it as an “official” build, as opposed to the (hopefully many) local builds that each of the developers does as they work on new features.

Of course, this may not be exactly what the Sublime devs are doing, but logically that’s the idea.

1 Like

#8

@OdatNurd Mmm, interesting, that makes sense actually, what you’re describing sounds like maybe they’re just using a software similar to Jenkins. If I recall correctly with this type of software you can customize the name of the artifacts by using git’s metadata as well as custom variables (i guess the major version in this case is one of them).

Anyway, I think I’ve got a rough idea by now how this might be done behind the curtains. So basically when I see in the changelog window “Build 3211” that means at least 211 artifacts have been produced internally for version 3 but only few of them have been released publicy, probably the build server will just release the ones tagged. In fact, I can imagine the “version commits” will be minimal&canonical and probably will just contain the edit of the changelog… Of course, this is just pure speculation but yeah, makes sense now.

Thanks! :slight_smile:

1 Like

#9

@BPL, the dev builds will fill in the build number gaps since not every change gets a stable release. FYI, sometimes dev builds are removed from the changelog if there are two quick releases (usually same day) due to some major regression or usability bug. Also note that dev & stable build numbers are never the same (no promotion, just new build for stable).

As for changelog contents related to the dev builds, the highlights of each dev build changelogs are used in the stable build changelogs… manually as bschaaf noted above.

1 Like