Release 2.3.1 -> Develop #171

sloum · 2020-05-29T02:39:57Z

sloum commented

2020-05-29 02:39:57 +00:00

Changes:

Changes Client.Draw() when bookmarks bar is closed. No longer adds in extra space chars. Should be easier to copy text and should have fewer instances of emojis deforming the page... all while simplifying the code!
Fixes querystring bug that prevented multiple status 1 returns in a row from gemini
Adds escaping to the querystring
Switches gemini relative URL handling to a go method in the std lib, which solves a number of problems with relative linking
Adds release target for make that will generate all four of the binaries we currently support
Updates readme regarding usage of GNU Make (with BSD Make not functioning with our makefile)
Increments version patch number
Fixes bug in makefile that prevented VERSION file from being used when appropriate (often the case for patch versions)

Changes: - Changes `Client.Draw()` when bookmarks bar is closed. No longer adds in extra space chars. Should be easier to copy text and should have fewer instances of emojis deforming the page... all while simplifying the code! - Fixes querystring bug that prevented multiple status 1 returns in a row from gemini - Adds escaping to the querystring - Switches gemini relative URL handling to a go method in the std lib, which solves a number of problems with relative linking - Adds `release` target for make that will generate all four of the binaries we currently support - Updates readme regarding usage of GNU Make (with BSD Make not functioning with our makefile) - Increments version patch number - Fixes bug in makefile that prevented VERSION file from being used when appropriate (often the case for patch versions)

🚀 1

sloum added the

release

label 2020-05-29 02:39:57 +00:00

sloum reviewed 2020-05-29 05:38:54 +00:00

Makefile

						
				@ -15,3 +15,3 @@

				# If VERSION is empty or not defined use the contents of the VERSION file

				VERSION    := ${shell git describe --tags 2> /dev/null}

				VERSION    := ${shell git describe --exact-match 2> /dev/null}

sloum commented

2020-05-29 05:38:51 +00:00

The previous --tags flag would always give the most recent tag, so would never use the file that was included. Using --exact-match means that if the exact commit that we are on does not have a tag an error will be returned on stderr (which we toss out) and we will read the version from the VERSION file. This is less buggy, if slightly more manual, and more inline with the intention from when jboverf set this par tof the makefile up.

The previous `--tags` flag would always give the most recent tag, so would never use the file that was included. Using `--exact-match` means that if the exact commit that we are on does not have a tag an error will be returned on stderr (which we toss out) and we will read the version from the VERSION file. This is less buggy, if slightly more manual, and more inline with the intention from when jboverf set this par tof the makefile up.

makeworld commented

2020-05-29 23:11:42 +00:00

First-time contributor

Are there any more tests to run before this can go through?

makeworld commented

2020-05-29 23:12:13 +00:00

First-time contributor

I'd be happy to do some if needed.

sloum commented

2020-05-30 01:49:58 +00:00

No, this is good to go. but the release process takes a little bit of time (updating website and gopher, adding tags to commits, building and packaging binaries) and I have not had the time to do it. It will for sure happen this weekend. After this I think I may be doing a code freeze on gemini related stuff... or at least, I am considering it. There is a lot of what I consider to be craziness on the mailing list lately and I do not know that I will continue to develop the gemini portion of Bombadillo past its current point. It is something I'll need to think on a little bit and see if I really want to maintain an ever more complex protocol. That said, I will certainly still field and respond, via comments, to any issues submitted and I will also make clear when this goes into effect and for how long. I'm still thinking it all out.

makeworld commented

2020-05-30 02:14:15 +00:00

First-time contributor

Oh okay, good to know. I think Gemini will be somewhat stable for a while now, so I don't think it'll be a big issue. I know Solderpunk would be sad to hear you describe it as an "ever more complex protocol" though.

sloum commented

2020-05-30 04:49:31 +00:00

I agree, solderpunk would be saddened to hear it, but I think they are feeling that as well (or it seems that way to me).

This post is really the straw that broke the camels back for me on this today.

The current state of Gemini support in Bombadillo (once this gets merged in) is reasonably stable and will work for some time. Hopefully things get ironed out a bit more over time and land somewhere solid with the spec. I do not care for a lot of the direction of discussion on the mailing list though, so we'll see.

I think where I am landing is that I will fix bugs for the gemini module (or approve merges for fixes to bugs) without any code freeze. However, I think I want to freeze on new features for a bit, as the conversation is just too all over the place. I also have decided that I do not want to support client certificates/transient certificates in general. I will keep the limited support that is built for them in the client, since people may already be using it (though I dont think so).

Gemini has gotten so much more complex than it was on first implementation. Back then I added it to Bombadillo on a whim... there was no content (only Sean's site). There was also only two line types: text and links. Easy to parse easy to deal with. No special rules. That is how Bombadillo ended up with the rendering as it is for gemini: mixed up with all other rendering. There just wasnt a need for separation at the time.

When solderpunk posted about project Mercury (I think mostly as a thought experiment, not as an actual suggestion), I realized that that was what I wanted the whole time: gopher with better link syntax, status codes, and mime. I dont really care much about TLS here (I think it is good for the web though), nor client authentication for secure areas or cookie-like behavior (those are both things I am trying to actively avoid by being on gopher in the first place). I would absolutely support mercury if it were to happen (it would be trivial to do so), though I dont see that happening... meanwhile it does seem like even solderpunk is realizing how big gemini is getting, and it looks to be getting bigger in scope with each mailing list message. That said, solderpunk it doing a pretty good job staying calm and focused about the proejct's goals.

Anyway, I'm trying not to make too reactive of decisions and just take things slowly. I have gotten a novel to read (Rendezvous With Rama) and would like to spend some evenings reading and relaxing for a bit, rather than catching up on the mailing list, doing updates, and coding. I will still be creating content on gemini (as well as my regular content on gopher), but maybe just need a dev breather for a bit (my wife has been reminding me to step away and take a breath and it sounds like a good idea about now).

Definitely feel free to keep adding issues as they come up. Features and bugs are both fine, but expect bugs to get dealt with and features to sit for a bit. I really do appreciate your help and involvement. The things you have brought to light have definitely made Bombadillo better. It is a bummer you got involved right around the time my feelings about gemini were starting to shift a bit. Again though, we'll see where things land.

Sorry for such a lengthy response! I have been thinking about this a bit and felt like I may as well write it all out here rather than make a melodramatic "I'm leaving gemini, at least for a bit" kind of post somewhere.

I agree, solderpunk would be saddened to hear it, but I think they are feeling that as well (or it seems that way to me). [This](https://lists.orbitalfox.eu/archives/gemini/2020/001176.html) post is really the straw that broke the camels back for me on this today. The current state of Gemini support in Bombadillo (once this gets merged in) is reasonably stable and will work for some time. Hopefully things get ironed out a bit more over time and land somewhere solid with the spec. I do not care for a lot of the direction of discussion on the mailing list though, so we'll see. I think where I am landing is that I will fix bugs for the gemini module (or approve merges for fixes to bugs) without any code freeze. However, I think I want to freeze on new features for a bit, as the conversation is just too all over the place. I also have decided that I do not want to support client certificates/transient certificates in general. I will keep the limited support that is built for them in the client, since people may already be using it (though I dont think so). Gemini has gotten so much more complex than it was on first implementation. Back then I added it to Bombadillo on a whim... there was no content (only Sean's site). There was also only two line types: text and links. Easy to parse easy to deal with. No special rules. That is how Bombadillo ended up with the rendering as it is for gemini: mixed up with all other rendering. There just wasnt a need for separation at the time. When solderpunk posted about project Mercury (I think mostly as a thought experiment, not as an actual suggestion), I realized that that was what I wanted the whole time: gopher with better link syntax, status codes, and mime. I dont really care much about TLS here (I think it is good for the web though), nor client authentication for secure areas or cookie-like behavior (those are both things I am trying to actively avoid by being on gopher in the first place). I would absolutely support mercury if it were to happen (it would be trivial to do so), though I dont see that happening... meanwhile it does seem like even solderpunk is realizing how big gemini is getting, and it looks to be getting bigger in scope with each mailing list message. That said, solderpunk it doing a pretty good job staying calm and focused about the proejct's goals. Anyway, I'm trying not to make too reactive of decisions and just take things slowly. I have gotten a novel to read (Rendezvous With Rama) and would like to spend some evenings reading and relaxing for a bit, rather than catching up on the mailing list, doing updates, and coding. I will still be creating content on gemini (as well as my regular content on gopher), but maybe just need a dev breather for a bit (my wife has been reminding me to step away and take a breath and it sounds like a good idea about now). Definitely feel free to keep adding issues as they come up. Features and bugs are both fine, but expect bugs to get dealt with and features to sit for a bit. I really do appreciate your help and involvement. The things you have brought to light have definitely made Bombadillo better. It is a bummer you got involved right around the time my feelings about gemini were starting to shift a bit. Again though, we'll see where things land. Sorry for such a lengthy response! I have been thinking about this a bit and felt like I may as well write it all out here rather than make a melodramatic "I'm leaving gemini, at least for a bit" kind of post somewhere.

makeworld commented

2020-05-30 15:46:34 +00:00

First-time contributor

I really wouldn't put too much weight on that post. It's a very frustrating tone, but it seems that that user is just stirring things up. It's not the way that Gemini is going, and it's not what Bombadillo needs to support, either. For example, it'd be totally valid for someone to put an ftp:// style link on their page, but it's also fine if Bombadillo doesn't support it.

I understand wanting to do a feature freeze, I think the Gemini support in Bombadillo is great now. I'm disapointed to hear about certs though, I think it'd be very cool to see some of the UI options Solderpunk has discussed (generate certs and reuse them, etc). But it would definitely complicate things.

Enjoy your evenings, and thanks for putting all your thoughts here. We'll see what happens with Gemini, but Bombadillo is a great client to use, and thank you for that.

I really wouldn't put too much weight on that post. It's a very frustrating tone, but it seems that that user is just stirring things up. It's not the way that Gemini is going, and it's not what Bombadillo needs to support, either. For example, it'd be totally valid for someone to put an `ftp://` style link on their page, but it's also fine if Bombadillo doesn't support it. I understand wanting to do a feature freeze, I think the Gemini support in Bombadillo is great now. I'm disapointed to hear about certs though, I think it'd be very cool to see some of the UI options Solderpunk has discussed (generate certs and reuse them, etc). But it would definitely complicate things. Enjoy your evenings, and thanks for putting all your thoughts here. We'll see what happens with Gemini, but Bombadillo is a great client to use, and thank you for that.

sloum commented

2020-05-30 16:50:52 +00:00

Thanks for the kind words and support!

I would potentially be open to someone else working on handling certs (with the usual caveat about not adding dependencies) and us merging that in I suppose. I wont say "I'll never do it"... but it isnt something I find myself using or wanting to work on.

I agree re: not supporting data links and the like. Coming from the early times with gemini dating back a year and a half when it was just an idea floating around everyone was coming from the same place (gopher/pubnix) and mostly held a similar set of ideals. It is just a little disheartening to see such a focus on graphical clients, style, layout, embedding, inlining, etc. It feels... not what I signed on for, but I suppose it is/was inevitable.

If anything I would like to see features like download monitoring, in program help, the ability to interrupt a request (stop). I think those would be better usability features for all users (not just gemini) and would be of bigger benefit than, for example, certs. But those are also tough problems. Some will get pushed to 3.0.0, but others may be able to make it in in the not distant future (possibly the in program help).

I'm going to merge this in now and get it to master and tag it. I wont be able to generate binaries or update the website and gopher for a bit (but likely in the next 24 hours or so).

I am enjoying the new book so far. I expected it to be denser in writing style, but it is really direct and to the point... which isnt always what I want, but it is good right now.

Thanks for the kind words and support! I would potentially be open to someone else working on handling certs (with the usual caveat about not adding dependencies) and us merging that in I suppose. I wont say "I'll _never_ do it"... but it isnt something I find myself using or wanting to work on. I agree re: not supporting data links and the like. Coming from the early times with gemini dating back a year and a half when it was just an idea floating around everyone was coming from the same place (gopher/pubnix) and mostly held a similar set of ideals. It is just a little disheartening to see such a focus on graphical clients, style, layout, embedding, inlining, etc. It feels... not what I signed on for, but I suppose it is/was inevitable. If anything I would like to see features like download monitoring, in program help, the ability to interrupt a request (stop). I think those would be better usability features for all users (not just gemini) and would be of bigger benefit than, for example, certs. But those are also tough problems. Some will get pushed to 3.0.0, but others may be able to make it in in the not distant future (possibly the in program help). I'm going to merge this in now and get it to master and tag it. I wont be able to generate binaries or update the website and gopher for a bit (but likely in the next 24 hours or so). I am enjoying the new book so far. I expected it to be denser in writing style, but it is really direct and to the point... which isnt always what I want, but it is good right now.

👍 1

sloum referenced this issue from a commit

2020-05-30 16:51:04 +00:00

Merge pull request 'Release 2.3.1 -> Develop' (#171) from release-2.3.1 into develop

sloum closed this pull request

2020-05-30 16:51:05 +00:00

sloum deleted branch release-2.3.1

2020-05-30 16:51:16 +00:00

Sign in to join this conversation.

No reviewers