Test & Code

Brian: 00:00

In the last episode, we talked about keeping a change log. Now, we're gonna talk about how to keep a change log with multiple contributors and not have a whole bunch of merge problems with this one file, the change log. In this episode, I talk with Ned Batchelder about a tool called Scriv. And in the next episode, I'll talk with Henick about Town Crier. I've I've got a project that I've, a couple projects that that I'm having, like, growing pains with the the release notes and, I guess, the change log, really.

Brian: 00:55

Yes. And so I was looking into how to how to deal with it. There's, like, a whole bunch of ways to deal with it. Yeah. So here we are.

Brian: 01:04

Here we are. Well, so let's jump into script. One of the options to deal with change logs is script. Yep. And it's something you created.

Ned: 01:13

Yep. By the way, you started by saying a tool to manage releases. This only does change logs and release notes. So for instance, it's not gonna pick your next version number for you or update your version number, things like that. Some tools do that stuff.

Ned: 01:26

This I did not take that on. Well, it's based on this idea that when you make a commit, when you you or, let's say, a pull request, you're gonna change some aspect of your code, that that is the moment when you should also write the change log entry or the release note, however you wanna look at it. They're the same thing as far as I'm concerned. But if you just have a big file at the root of your repo called, you know, change log dot MD or something, then when you make your pull request and you put your change log entry at the top of it, you're gonna conflict with someone else who's also making a feature at the same time and putting their change log entry at the top of change log dotmd. And those merge conflicts are a problem and a headache.

Ned: 02:10

So this this tool works the way a number of other tools do, which is when you make your commit, you also write a a small file that contains just the fragment of the change log for the change you're making. And that fragment goes into a directory. And then later and when it's merged, that file will get merged into the main branch. And when you make a release, you will look at all of those fragments in that directory and combine them to make the change log that should go with that release. Okay.

Ned: 02:40

That's the idea. Yeah. And and and so I I had experience with a large project with many developers years ago where we just had a big change log file at the top of the repo, and they were always complaining about merge conflicts. And I changed the instructions to be, don't put your entry at the very top of the file. Just put it near the top of the file in the hope of avoiding merge conflicts.

Ned: 03:03

And the engineers would come to me and say, what do you mean near the top? Like, the engineers couldn't deal with something as vague as near the top of the file. They wanted to know exactly where to put it, and so that didn't work.

Brian: 03:13

Well and I guess this might actually go towards, like, problems with merge tools. I mean,

Ned: 03:22

it could. Because To be fair to the merge tools, if if you and I both put a paragraph in exactly the same point in the file, it's the merge tool is gonna rightly say you both tried to change the same line in the file in different ways. Now you could maybe have a merge tool that is clever. You know, you can direct it that for this file, you just wanna take both changes. But there's other aspects too.

Ned: 03:46

So for instance, if if I add a feature and then add a feature and then fix a problem and then deprecate something and then add a feature, I don't want them to appear in chronological order in my change log. I want all of the added features at the top.

Brian: 04:01

Yeah.

Ned: 04:01

And then I want the fixes and then I want the deprecations. Right? So there's a categorization of the entries that should happen that that isn't based on strict chronology, and a merge tool is never gonna get that right.

Brian: 04:14

Okay. So what's the so so the workflow is if I when I make a change, for some reason, I, what what so when do I add the little blurb, the little extra thing?

Ned: 04:28

So it should go into your pull request. Let's say you're doing a pull request workflow, right, where so every change you make to the project is gonna go into a pull request to be reviewed by someone. One of the files in your pull request would be the change log fragment.

Brian: 04:41

Okay.

Ned: 04:41

In in script terms, you would use the script create command, and it would make a new fragment file in your change log dot d directory or whatever it's called. That file would be added as to your git commit, and it would be part of your commit. It would be part of your pull request. It would get reviewed as part of your pull request, and become part of the merge to main when the pull request was merged.

Brian: 05:06

Okay. And so, one of the other things I was looking at was Town Crier, and it does a similar thing. Right?

Ned: 05:13

Yep. It does. It's very similar.

Brian: 05:15

Okay.

Ned: 05:16

The big difference between Town Crier and Scriv is that Town Crier is extremely opinionated. It has a very quirky style of collecting the fragments. So for instance, I think it is that the file extension of the text file indicates whether it's an add or a change or a fix, which just seems strange that the file extension should be what the format of the content is, not, you know, whether it's a fix or a change. Yeah. So one of the things I was experimenting with with script was being extremely flexible and configurable.

Ned: 05:51

And and there were two reasons for that. 1, I started Scriv about two and a half years ago when black was in its ascendency, and it was famous for having no options. It's extremely opinionated. I thought, well, I'll I'll try the opposite. Let's have all the options and no opinions.

Ned: 06:07

But the other thing is that I was hoping, and this hasn't worked out, I was hoping that script would be adopted by my work project, which is the large open source project called Open edX. I was hoping that it would be adopted there and used for all of its repos. And I already knew that there were RST people and markdown people and NPM versus Python and lots of repos there where there wasn't gonna be a single culture that could use one quirky tool. It had to be a flexible, configurable tool. So that's that's where I where I went with script in terms of its design.

Brian: 06:40

Okay. Well, that's cool. I'm I'm happy about the markdown bit.

Ned: 06:45

Yep.

Brian: 06:45

So how do I tell if it's not an extension part, how do I tell it if it's a bug fix or a feature or something?

Ned: 06:52

That's a great question. So so the structure of a fragment is that there is a header, which is got a category in it. So it's, you know, it says fixed and then the underlines if you're in RST or or a hash mark fixed if you're in markdown.

Brian: 07:06

Okay.

Ned: 07:06

And then the content and understands enough about the structure of both markdown and RST that it can look at that fragment and see that it is a fix or an ad and then when it collects them together to create the change log during a release, it will put the category pieces together and you know in the same categories go together. And another advantage by the way of it being understanding the markdown is that you can actually manage a markdown a change log file. You might have a change log dot MD. I could make a pull request and write a fragment dot rst, and you could make it fragment dot MD. And then when we collect them, it'll actually get all transmogrified into markdown because the change log file is a markdown.

Ned: 07:49

So it's trying to be very, structured about the content in a way that lets it be a bit agnostic about what comes in and what goes out, those sorts of things.

Brian: 08:00

So okay. So during a merge request, I do a, script I already forgot it. Script create create fragment. Okay. And then, and then these get populated in a change log dot d directory.

Brian: 08:16

Yep. And then and then at some point, I've got a whole bunch of changes on main.

Ned: 08:20

Yep.

Brian: 08:21

And I say, let's do a release.

Ned: 08:23

Right. And so part of your release process will be script collect

Brian: 08:27

Okay.

Ned: 08:27

Which will combine all the fragments. It'll delete the fragments from Git. It'll add the changes to the change logs as to Git. And now you've got a combined change log file that could be checked in as part of your you know, the the final 2 or 3 commits of your release process.

Brian: 08:42

Okay. And then the the actual versioning, is it get involved with that at all? Or

Ned: 08:50

No. So script doesn't have an opinions about the versions. It doesn't update your version number. It doesn't go and edit your, you know, dunder init.py or whatever where your version number is. Okay.

Ned: 09:01

It understands enough. You can tell it, you know, here's where you will find my version number so that you can include it in the header of the change log.

Brian: 09:08

Okay.

Ned: 09:09

And there's a third command, for for script called GitHub release. So I've always maintained my own, change log files. And then because I write Python code, I release them on PyPI. But GitHub has these releases, and people seem to want GitHub releases for some reason. I'm not sure why it's exactly duplicative of information that's elsewhere.

Ned: 09:34

Okay. I don't know. Does anyone actually download, like, the dot tar g z's or dot zips from the GitHub release page in order to do a thing with software if they've got NPM or PIPI.

Brian: 09:44

I don't know.

Ned: 09:45

Real package management. I don't know. But anyway, people seem to want GitHub releases. And so, screw of GitHub release will read your change log file, parse it, and create a GitHub release with the same information. So it's duplicated information, but at least it's automatically duplicated rather than having to, edit a GitHub release in some way.

Brian: 10:08

Okay. Yeah. Well, so, like, one of the thing the other ones, that I've looked at is, what is it, the release drafter Okay. Which which is definitely part it's, like, embedded in the GitHub world.

Ned: 10:24

Yep.

Brian: 10:24

So, and does and so that's that in that tool, you it doesn't even save a release. You can, but it doesn't save a a a change log to your repo.

Ned: 10:37

Right. And I I have opinions about that. I GitHub is great, but all of the information about your project should be in files in your git repo. The idea that you've got a change log and it's not a file that I can read on disk when I clone your repo just seems really strange to me. That is incredibly important information about the history of your project.

Ned: 10:57

Why wouldn't you want it in a file in your project?

Brian: 11:01

Yeah. It also allows you to grab main and none of the other none of the rest of the history if you just wanted to shallow, clone and still get information about it. So

Ned: 11:10

Right. Exactly.

Brian: 11:12

Right.

Ned: 11:13

I I was taught long ago by a release manager from Debian that the source distribution of your project should be all of the files needed to create and continue to maintain that project in the event of a nuclear disaster. And and nothing if there's anything that you need that isn't in the that source distribution, then you have left something behind that's important.

Brian: 11:37

And the

Ned: 11:38

idea that somehow GitHub releases is the the source of truth for the history of your project just seems really strange to me. The other thing that seems really strange to me are these tools that take that make a change log by just grabbing all the commit messages. Commit messages and change logs are are different things, and they've got different audiences. And you should write different information for different audiences.

Brian: 12:03

Okay. That's an interesting take on that that you yeah. So in order to get these, these commit messages to read well, you've gotta, like, actually think about it when you're committing stuff there.

Ned: 12:18

Yes. Oh my gosh. Wait a second. Think about it? Yeah.

Ned: 12:23

No. I'm I'm a huge fan of the idea that writing is a great way to explain things to people, but it's also a great way for you to understand what you are thinking about is to write about it. And I have often found, you know, I'll make a change, change the code. Yeah. Change looks good.

Ned: 12:38

Okay. I guess I get it right thing now about what I just did. And in the process of writing the change like message or, you know, a detailed commit message as some people some people do, I will realize something about what I've done and maybe I'll, you know, tweak a name to be better, or I'll think of an edge case that I missed. And I I'm just a huge fan of writing as a way of understanding for yourself.

Brian: 13:02

Yes. Yeah. I definitely but there I I wanna just be realistic that there is there is some differences between, a commit because I I commit to my own branch because I I wanna get I wanna it's at the end of my day or something, and I want or it works now, and I wanna, like, have a starting point before I start changing some more stuff. And the mindset of a pull request where I think I actually am ready to push this code into the rest of the

Ned: 13:30

code. Absolutely.

Brian: 13:33

Yeah. They're they're different mindsets. So No.

Ned: 13:36

I I understand that. And I've got side projects where I don't keep release notes, and I have very sketchy commit messages. But if you are if you are supporting a project seriously and you have an audience that's trying to use your code, I really think it's worthwhile putting some time into writing change log entries that are designed to be read by your users rather the and also commit messages that are designed to be read by other developers on your project. And they are different people with different needs. Yeah.

Ned: 14:08

That's that might be controversial. Developers don't wanna write twice. Maybe it's the same text. Okay. Copy and paste it.

Ned: 14:14

That's fine. One idea for a future feature of script is to be able to pre populate the change log fragment with your commit messages. So at least if you've written a bunch of words that are useful, you'll have them as a starting point even if I don't just literally make it the next change log entry.

Brian: 14:32

Okay.

Ned: 14:32

It doesn't do that yet, but that would be cool.

Brian: 14:35

Yeah. Yeah. So you you started by talking about this being, not opinionated. Like, black is opinionated. But Right.

Brian: 14:46

Clearly, there's some opinions. But

Ned: 14:48

Well, I personally have opinions about what is what the the value of writing. Yeah. But if you want markdown, that's fine. If you want RST, that's fine. For instance, the script does not have an opinion about what categories of change log entries there are.

Ned: 15:03

There's a default of, you know, fixed, added, changed, deprecated security, whatever. But you can make up your own categories, and it'll it'll be fine with them. How you wanna structure your change log, is it a is it a piece within your read me already, or is it a separate file? You know, all of those questions are things that can be configured within script.

Brian: 15:23

Okay. And By

Ned: 15:24

the way, if if someone out there wants to use script and they cannot because there's some aspect of their workflow that it cannot do yet, get in touch. I'd be very interested to hear about what that is and to help it adapt.

Brian: 15:37

The the other question I have is or I probably have more. But, any question is when like, at what point in a project should I use something like this rather than just writing hand handwriting a change log?

Ned: 15:51

Yeah. That's a good question. Def definitely. So right now, I use Scriv on itself and on another of my side projects, 2 of my maybe 2 or 3. And there, it's a little strange because I'm a sole developer.

Ned: 16:04

So I could just edit the change log dot rst. In fact, for my primary side project, coverage dotpy, I do just edit literally a changes dot rst file, and that's because that project predated by a decade's scriv. So I haven't thought about yet whether I wanna pull scrip into that workflow. But if you have multiple developers, then this definitely helps avoid that traffic jam at the change log file. For instance, CPython itself has a tool, not Town Crier, a separate tool a different tool.

Ned: 16:41

I forgot what it's called. But it has, again, the same idea. You make a news entry, they call it, in a directory, and then there's a process that aggregates them together for final publication. It just it just keeps developers out from it keeps them from conflicting in that one file that they all have to edit all the time.

Brian: 17:02

Yeah. So and I'm I'm trying to play with it. I'm considering starting using some sort of extra process just for even sole developer projects because a workflow that I've often done for little projects is just, if I change anything, I'll do another release. Right. Because I might not actually work on this project for another month or 2 or something.

Brian: 17:31

So and I'll forget what I did. So go ahead and release it. But sometimes there's like, it's silly. It's like a a you know, I I put off things like formatting changes and different things because well, that's probably not gonna go into a change log. But there's a but then I have to, like, hunt down what what I did.

Brian: 17:50

So I'm actually thinking about trying to add something like this just just for my own sanity's sake, just to keep track of things that I don't touch very often.

Ned: 17:59

Right. And, you know, it's the point you make is an interesting one. I've I've been trying to release more frequently. I you almost came up with a philosophy, which is your change log should only have one entry per release because every time you make a change, it should be a release. And in some ways, yeah, why not release that frequently?

Ned: 18:18

I don't know. I just haven't gotten quite into that mindset of releasing quite that often. But I'm I'm getting there. I'm getting closer.

Brian: 18:25

And that well, I've heard other people say they, will try to they'll build up some stuff until, like, and and just, like I don't know. There's a regular cadence, like, every couple weeks if they're they've been working on it, go ahead and release extra stuff. And, and definitely, like, if if it's an active project, that that makes sense. If you've got, like, multiple changes coming in a day, you don't want 5 releases a day. I mean, maybe you do.

Brian: 18:52

I don't know. It does seem a little confusing on the consumer side to have

Ned: 18:56

Yes. A lot. I and one part I haven't looked into it, but one project I have noticed because I use it on coverage dot pie is hypothesis, which seems to go the multi release per day route. And it is a little bit confusing. And for instance, at work, one of the things we have to do is keep our 3rd party dependencies up to date.

Ned: 19:14

And if a library is changing, like, every time we run make update, that library comes in, and we have to think about what changed on it. That's that's taxing on us. Yeah. So I'm I'm not sure every change deserves a release, but I'm trying to be more frequent about it.

Brian: 19:31

Okay. Well, on my list of people to talk to is, somebody about hypothesis. So, you know, maybe.

Ned: 19:38

Is that Zach?

Brian: 19:39

Yeah. Yeah. So he was at, he was at Pike, Piebay. So I was on a on a panel with him. Seems like a nice guy.

Ned: 19:47

Yeah. But,

Brian: 19:49

like, what's up with the multi day multi releases per day thing? So he's he's in the US now. I I thought he was in he was in Australia for a while.

Ned: 19:59

I don't I don't know. I he it's funny. But during the pandemic, we you know, I'm running Boston Python. And during the pandemic, we were all virtual. And so we had visitors from all over the world, and Zach dropped in on one of our, events.

Ned: 20:11

That was cool.

Brian: 20:12

Yeah. So, I I guess maybe I need to play with all of these to see what what it what they feel like.

Ned: 20:20

Okay.

Brian: 20:21

And and see what it see what it feels like. Now this so this doesn't depend like you said, it doesn't depend on GitHub. So I could use I could use this for internal projects as well.

Ned: 20:32

Sure. Yeah. The only connection well, it's it's connects to Git. It knows so for instance, when you do a script create, it can do the Git add for you, and it will launch an editor the way it does to edit the fragment. The GitHub release command, of course, is connected to GitHub, but, you know, in a lightweight way.

Brian: 20:55

But if I have an internal, as long as this Git, it should work. Sure. GitLab or something.

Ned: 21:00

In fact, you don't even have to use the Git features. You could just use it to maintain files for you and do your own Git add or Perforce add or whatever it is you'd need to do.

Brian: 21:10

Okay. So, other than okay. So we're talking about Scriv, but you're you're kind of a big deal, Ned.

Ned: 21:19

Me?

Brian: 21:20

Yeah. No.

Ned: 21:20

That's too much pressure.

Brian: 21:23

So so what's what's going on in your life and your Python world and life and everything? And

Ned: 21:30

that is that's a well, big open ended question.

Brian: 21:35

Sorry.

Ned: 21:36

That's okay. You know, I've got side projects going. One of my other side projects is a thing called dingy, which was designed for me to keep up to date with activity on GitHub. I I had to follow too many projects and watch projects and GitHub projects that is not open source projects. And so I wrote this thing called dingy to use the GitHub GraphQL API to to do stuff.

Ned: 22:06

I keep mentioning it to people at work who complain they can't keep up with stuff. No one else has adopted it but me, but that's fine. It works well for me.

Brian: 22:13

So is this a open source thing as well? Oh, yeah. Okay.

Ned: 22:16

Oh, yeah. And,

Brian: 22:21

I

Ned: 22:21

don't know.

Brian: 22:21

See it. I you've got COGS been, it goes it it goes in waves, I think, if people adapt to COGS. So

Ned: 22:29

Yeah. Cog is cog is the tool I wrote to inject little bits of computed content into plain text files, basically. And I continue to use a lot. I just I just wrote some cog fragments the other day. And it seemed and I I got actually, I got contacted by a Python core developer, I think just yesterday about cog, because people it's one of these things that grows really slowly over time.

Ned: 22:54

Like, it's not blowing up, but and it's been around for 15 years or something. But,

Brian: 23:00

it's going there. Do what we can do about it.

Ned: 23:03

No. It doesn't it doesn't need I I think we it was mentioned the other day, some last year or something as like it took 15 years to be an overnight success, you know, that kind of project.

Brian: 23:14

Yeah. And, like, in supporting coverage, of course.

Ned: 23:19

Supporting coverage, which is a big thing. 3.11, which is coming out in October, I guess, within a few weeks. 3.11 made a number of large changes in the execution of Python in the in the pursuit of speed, which they've achieved. I think it goes about 25% faster than 3.10. But as a result, there was a bunch of upheaval with esoteric things like coverage that need to track execution.

Ned: 23:44

And that is now behind us, I guess until maybe 3.12 speed improvements come down the pike. Okay. But, yeah, maintaining coverage is is still a thing. I do a release maybe about once a month, once every 2 months, but they tend to be small fixes. The problem with coverage is that I get these bug reports about these crazy esoteric things like, oh, it doesn't work with TensorFlow.

Ned: 24:07

And I think, I can't even spell TensorFlow. I'm not gonna be able to debug that. And I try to get attention from TensorFlow people, and they don't know what coverage is. And

Brian: 24:18

Okay. Yeah. Yeah. So I guess, very popular projects, double edged sword, I guess, for, for you. You're not are you the you're not the sole maintainer coverage, are you?

Brian: 24:30

Or are you just

Ned: 24:31

the I am. Yeah. Basically, I am. There's I mean, I get pull requests from people and a lot of help in in that way, but there is not another person who can review the code for for me or with me.

Brian: 24:42

Okay.

Ned: 24:43

Or knows how to release it or anything like that. So yeah. Okay. This will be cleaner.

Brian: 24:48

I guess, thanks then because we all love coverage. So, well, cool. Any and and you're you're involved with the Boston a little bit involved with the Boston meetup. Right?

Ned: 25:02

Yeah. So I used to be the, like, sort of the the main guy who did everything for the Boston Python meetup, but I've been really lucky in having other people show up and say they wanna do things, and then they do them. Nice. Yeah. So for instance, Brian, your book about your second edition of the Pytest book is now a book club that's being run by one of our our newest organizer who I've never met because he joined the group during the pandemic.

Ned: 25:27

And he said he wanted to do a book club, and I said, that sounds hard. I don't know how it's gonna work, but he said, I'm gonna do it, and he's doing it, and it's great. And Oh, awesome.

Brian: 25:36

Yeah. And it's is it still virtual then?

Ned: 25:41

We yeah. We haven't yet gotten back to to physical in person meetups part of partly just because everyone's still a little skittish, but also because even in before times, it was hard for us to find hosts that could host us because we would tend to get 80 to a 100 people. Yeah. And so now we have to find hosts that are both large enough and don't mind the risk of hosting in person events. And right now, we're entering back into the cold season, which tends to give a little bump to things, but everyone's vaccinated, so maybe it won't be a problem.

Ned: 26:14

So I don't know. Something will probably happen pretty soon.

Brian: 26:18

But I kind of I mean, there's there's definitely need for that, for people to actually get to get together and and see each other in person, especially if they don't have colleagues that they interact with much.

Ned: 26:30

I know. I have a feeling the first the first back to person in person event we do, everyone's gonna be, 1, really excited, and 2, will think we really should have done this a year ago.

Brian: 26:40

Okay.

Ned: 26:41

That would be my guess.

Brian: 26:42

But there's probably a non zero portion of the population that really wants them to stay remote so that they can, you know, attend without commuting.

Ned: 26:53

Yes. Absolutely. In fact, Glenn, who is is running your book club, the book club for your book, I should say, lives, I don't know, an hour or 2 north of Boston. Yeah. And so feels an affinity to a Boston meetup, but probably wouldn't attend in person.

Ned: 27:10

It would be difficult for him. We're doing weekly office hours now, and one of our regular attendees of the office hour, I think, lives in Mexico.

Brian: 27:19

Nice. And,

Ned: 27:20

you know, why not? Right?

Brian: 27:21

Why not? Yeah.

Ned: 27:23

So, I mean, during the pandemic, I was wondering, what does the word Boston mean in Boston Python meetup anymore? But I don't know. You're not gonna have a worldwide meetup.

Brian: 27:34

Right. So yeah. Because you you gotta at least pick a time zone.

Ned: 27:37

Yeah. Yeah. You have to at least pick a time zone. That's right.

Brian: 27:43

Yeah. Anyway, well, cool. Well, thanks for your time today, and thanks for describing this to me.

Ned: 27:51

Yeah. Yeah. Scribe is another of these projects that started very slowly. In fact, I was I was kind of astonished to realize as I was going back through the history that I started this two and a half years ago. And it right now, as far as I know, it's only being used by 3 of my side projects.

Ned: 28:08

But I think other people are using it because I'm getting feedback, but it's not it has not hit the big time yet. Maybe it never will. That's fine.

Brian: 28:16

Yeah.

Ned: 28:16

It's been fun to work on.

Brian: 28:19

Well, I I just I have a couple stupid things that I I kick around my that are useful for myself. Exactly. And then but then sometimes some of them start getting used by other people. And then and then I start kind of caring about not being a dork and just changing things willy nilly. Yeah.

Brian: 28:36

It's tricky.

Ned: 28:37

But but at the same time,

Brian: 28:39

I still want the I think I should have the freedom to do that. I mean, it's my project. Right? But at the same time. Yeah.

Ned: 28:47

I think it's in in when it comes to that, I think the important thing is to be clear about it. Like, you could put into top of your read me, feel free to use this, but I don't care. I'm gonna do what I wanna do.

Brian: 28:58

May change at any moment.

Ned: 29:00

Yeah. Or, like, I might I could have put at the top of Scriven. I'm using this now. I don't know if anyone else is. If you are, please let me know so that I can start to wonder whether I need to be careful with it or not.

Brian: 29:11

Mhmm.

Ned: 29:12

You know, we tend to get these very formulaic readmes that try to present everything as if they're, you know, the next thing that's gonna change the world. But like you said, like, we're just one dude sitting in our room hacking on some code because it was interesting for a little while. Why can't we be transparent about that in our read me's?

Brian: 29:29

And okay. So you your your code doesn't, enforce any versioning or anything. Portion

Ned: 29:38

of doesn't. No.

Brian: 29:39

Okay. Are are you a semantic version kind of person, or do you

Ned: 29:43

I am. Yeah. I try to be. I mean, it's a little tricky because semantic versioning is based on the idea that there is a well defined interface, and you need to know whether you have changed it or not. And often, that is very difficult to determine.

Brian: 29:56

Well, with Python, you can reach into anything. So the entire code base is an interface.

Ned: 30:00

Yes. Well, there's that. For instance, I mean, I've had that problem with coverage dot py, and I tried to be strict about it. Like, I documented a bunch of stuff. I'm making promises about that stuff.

Ned: 30:10

And if it's not documented, you're you're on your own. I'm not gonna I'm not gonna bend over backwards to deal with that. But, you know, things like I mean, here's the example I've used before, pilot, right, which which issues violations for your code. If the set of violations changes, is that a breaking change for pilot? Because their interface is we read your code and out comes a set of violations.

Ned: 30:35

I don't know what anyone would think it is, but in a way, that's their interface. So

Brian: 30:41

and Like, if they add a new one If

Ned: 30:43

they add a new one or or if something tweaks and so they set the the times it appears changes. Yeah. Is that an interface? I don't I don't know. Well, so

Brian: 30:55

I I was, so the like, you know, there's so many of these corner cases with semantic versioning. So I've I've I've, talked to somebody about the the calendar for Calver.

Ned: 31:05

Calvert.

Brian: 31:06

Yeah. Interesting. Just just bump like the the other digits are the same, but the top one, you'd bump it every year.

Ned: 31:14

Well, that's what Pip does, right? Pip is is Calvert calendar versioning.

Brian: 31:18

Yeah. So, and I was thinking, like, to force people to read the change log, just do Randver, just a random number generator Randver.

Ned: 31:28

Okay.

Brian: 31:29

That that picks a version for you.

Ned: 31:31

But is it at least gonna be monotonically increasing, or are you gonna have, like, version 3 after version 4?

Brian: 31:36

Sure. It can just be any version. It just, you you have to pin it. It can't be a less than or equal or anything like that.

Ned: 31:45

That would be mean. I mean, you you would get some hate mail, I think, if you really did that. But Or I guarantee you not to have any users of your of your tool.

Brian: 31:54

Okay. Well, the the real RanVer probably isn't a random number generator, but just it's it looks like semantic versioning, and they keep growing further, but you don't know if it's gonna break between major versions or not.

Ned: 32:08

Yes. Well, remember, Donald Knuth, when he produced his tech, text formatting system, used versions where the version number was pi and he would add a new digit to the end of pi.

Brian: 32:20

I didn't I don't know that.

Ned: 32:22

Yes. So the and and that was because he really had this feeling like I am I am asymptotically approaching this thing being literally done. Like, it's not just gonna grow forever. It is nearing perfection. So we'll just add one more.

Ned: 32:37

And URL 3, I think, did the same thing. Right? 0.9999999 was a version of theirs. There's plenty of innovation to be had in the versioning game.

Brian: 32:47

Yeah. Yeah. Okay. Yeah. Anyway, well, I could probably be us with you a whole bunch.

Brian: 32:53

And if I wanted to, I probably should show up at the buy stuff Boston meetups more.

Ned: 32:57

So well yeah. Yeah. Sure.

Brian: 33:00

Cool. Well, thanks for your time, and, catch up with you later.

Ned: 33:04

Okay. Bye. Alright. Bye.