Is it release time?

[JulienPalard]

I noticed glowing-bear has not been release since july 2020, I would enjoy more frequent releases.

(Or is everybody just using latest.glowing-bear.org?)

[lorenzhs]

There isn't all that much to release though, right? 🙃

[lorenzhs]

If I can figure out how the release process works I can try to make a release next week

[PhrozenByte]

Are 192 commits with 14,690 additions and 2,029 deletions in 78 files enough for yet another release? I know, it has been just 3 years, but... 🙃 😆 👍

Okay, seriously, I'm thinking about switching to Glowing Bear, it looks like an ❤️ project. Great work! 👍

However, the apparently missing versioning is kind of an issue - and kinda daunting. I'm about to run Glowing Bear in a container and want to do automatic updates, but without releases I can't reliably do this. Applying any commit from master is just too risky to break stuff. Even though the old version apparently still runs fine, some - even very irregular - releases - even with most basic manual testing imaginable ("connecting and writing a message seems to work, so yeah, looks fine") - would be a huge improvement.

[lorenzhs]

Development here has kinda stalled - Glowing Bear builds on top of the old, discontinued angular framework (see https://en.wikipedia.org/wiki/AngularJS), which was discontinued five years ago and even LTS support ended 1.5 years ago. There is no good way forward with this code base. And most of the developers have largely lost interest.

That said - #1264 has a few small dependency updates etc to get v0.10.0 into release shape, and #1265 would push that to the deployment branch (gh-pages). Can you test that the contents of that branch (https://github.com/glowing-bear/glowing-bear/tree/lorenz/release-0.10.0-deploy) work for you when served up locally? It's basically the result of npm run build, served up as the gh-pages folder.

[lorenzhs]

Release is blocked on #1263

[PhrozenByte]

And most of the developers have largely lost interest.

What's the reason for that? Is Glowing Bear considered "feature complete" (this doesn't have to be "absolute", i.e. if the devs say "it's fine for me the way it is" it can be considered "feature complete")? Or do people use something else? If yes, what do they use instead? Didn't find any alternatives besides plain WeeChat. Or are people no longer using WeeChat? If yes, what do they use instead?

Can you test that the contents of that branch (https://github.com/glowing-bear/glowing-bear/tree/lorenz/release-0.10.0-deploy) work for you when served up locally?

Sure, I can build this version and give it a try. Thanks! 👍

However, this doesn't really solve the "missing release process" issue, right?

Release is blocked on #1263

If you couldn't reproduce it (i.e. the issue is not very common) I don't think that it should block a release for too long. If it's a bug in Glowing Bear and has been fixed, one can create another release. Affected users might switch to an older version of Glowing Bear in the meantime.

[lorenzhs]

What's the reason for that?

Speaking for myself, I just don't use IRC any more 🤷

However, this doesn't really solve the "missing release process" issue, right?

Sure, but what's the point in having a release process for a code base that's largely dormant?

And re: #1263, I point you to my first point again, which is "I just don't use IRC any more". But it appears to be an annoying regression, and I won't push out a release with a regression like that, sorry. Especially since the hosted version is for the latest release only.

[PhrozenByte]

Sure, but what's the point in having a release process for a code base that's largely dormant?

I guess, because there's still development happening - "largely dormant" is not "dead", right?

A dead project should be treated such, i.e. archived on GitHub with a big "discontinued" warning in the README.md. However, by looking at the commit history, it's evident that Glowing Bear is not dead. Maybe there's not so much active feature development happening, but maintenance surely does happen - and if it's just merging Dependabot's PRs.

And there's absolutely nothing wrong about that! Quite the contrary, by looking at the commit history, a huge 🙇 and ❤️ to you that you still maintain Glowing Bear, even though you're not actively using it yourself! 👍 Free time is very precious and doing volunteer work on FLOSS software is very admirable. I try to do the same and thus know the struggle.

Since maintenance is indeed happening, there should be a release process of this maintenance work. There's nothing wrong about bumping the version even for small maintenance updates.

The problem right now rather is that there was no release for way too long, so that the next version indeed includes some rather major changes. I agree that this needs some testing. I'll do some testing and report back in a few days. However, after that there should be a release process, otherwise Glowing Bear will get into the same situation again. I mean, even after tagging a new release it's just a few months till the stable version at https://glowing-bear.org/ is outdated again - thus there should be a release process.

By the way, could you merge #1266 ? Since you don't want to release it yet the version number shouldn't be bumped yet.

Okay, enough abstract talk, let's get down to actual improvements:

Even though I do know JavaScript, I'm not very good at it. My JavaScript skills are very outdated and I'm definitely no Angular developer (neither AngularJS, nor Angular). Since it's unlikely that this will change I simply can't do maintenance work myself.

However, what I can do is helping to implement a release process. For example, I could write a GitHub workflow to run the existing test suite for new commits and PRs, I could write a Makefile to bump versions and push a new GitHub release, and I could write a then triggered GitHub workflow to build Glowing Bear for the matching Git tag and push the results to the gh-pages branch. This way bumping and releasing a new version is no more than running make publish, making it as easy as possible for the devs doing the maintenance work.

Before I do that, I need to know whether this is wanted and whether there's anything I should consider (like "don't use this, use that" and "don't do it like this, but like that"). For example, I don't see a reason why only the latest version is available at https://glowing-bear.org/, we could easily keep the old version in a sub-directory to allow people to switch back to the older version in case of regressions (like #1263).

By skimming around I saw that the Cloudflare Pages app is active and still in use. What does this app do and does it affect a possible release process? Travis CI looks abandoned, but I prefer GitHub workflows anyway, they are way easier to use. Anything else to consider?

@torhve what are your thoughts about this whole story?

[PhrozenByte]

@lorenzhs @torhve Any updates?

By the way: I'm running latest Glowing Bear for a few weeks now, couldn't reproduce #1263.

[PhrozenByte]

@lorenzhs @torhve ping

[cormier]

Hi @PhrozenByte

I agree with your July 9 note and believe that there should be a release process that is more automatic than the one we currently have (https://github.com/glowing-bear/glowing-bear/wiki/Releasing).

I haven't worked on the project for years and I'm the least active maintainer, but maybe I can help you setup something that we will all find useful. 😄

Since there is a lot going on maybe we could formalize a specific proposal, get feedback from @lorenzhs and @torhve, and then I would add it to the wiki

However, what I can do is helping to implement a release process. For example, I could write a GitHub workflow to run the existing test suite for new commits and PRs, I could write a Makefile to bump versions and push a new GitHub release, and I could write a then triggered GitHub workflow to build Glowing Bear for the matching Git tag and push the results to the gh-pages branch. This way bumping and releasing a new version is no more than running make publish, making it as easy as possible for the devs doing the maintenance work.

Would it be possible to do without the Makefile and just trigger the release when a tag is pushed ?

Before I do that, I need to know whether this is wanted and whether there's anything I should consider (like "don't use this, use that" and "don't do it like this, but like that"). For example, I don't see a reason why only the latest version is available at https://glowing-bear.org/, we could easily keep the old version in a sub-directory to allow people to switch back to the older version in case of regressions (like #1263).

Sure, should we just keep "latest" and "previous version" ? How many versions do you think we should keep ?

By skimming around I saw that the Cloudflare Pages app is active and still in use. What does this app do and does it affect a possible release process?

I'm not sure it is used -- I will look it up.

Travis CI looks abandoned, but I prefer GitHub workflows anyway, they are way easier to use.

I believe Travis was the only option when we integrated it (circa 2013). I haven't used GitHub workflows yet but I would be open to the change.

I will try to get back to you shortly. Also, feel free to reach me on IRC if you have any question

Cheers

[PhrozenByte]

Since there is a lot going on maybe we could formalize a specific proposal, get feedback from @lorenzhs and @torhve, and then I would add it to the wiki

👍

@lorenzhs, @torhve, or @cormier can you please give me a sign whether you're willing to review, merge, and especially use such a PR before putting effort into this and formalizing a specific proposal? As for everyone else time is very limited and I just want to be sure that the work is actually used later.

Our goal should be to get Glowing Bear back to a "maintained" status. Therefore I'm not asking anyone to invest more work into Glowing Bear than before, just that maintenance that was happening before gets released - even if these updates are tiny. This includes releasing all changes since the past three years shortly after setting up the release process (i.e. releasing 0.10.0 as soon as the new release process is implemented).

Is this a path we can commit on @lorenzhs, @torhve, @cormier, or rather not? If not, please just say so, no hard feelings at all, you decide what to do with your free time. However, if not I'd ask for adding a note to README.md that Glowing Bear is currently unmaintained, a new maintainer is looked for and the project is discontinued for now. If nobody is asked to take over responsibility nobody will accept it.

By the way, still no sign of #1263, so this either was just a hiccup, or maybe an issue with WeeChat that was fixed in the meantime.

Would it be possible to do without the Makefile and just trigger the release when a tag is pushed ?

Yes. We don't really need a Makefile, I personally just like to use Makefiles because they are universally understood, but I can surely just also create a deploy.sh script (possibly called via npm run deploy) taking the necessary steps. The only important thing here is that we check whether a commit is deployable (like running the test suite, checking whether the version strings were updated, checking whether npm run build doesn't fail, etc.) before pushing the tag, because a tag that has been pushed is a release already (even if deployment fails later; thus we must run these checks first). The deployment of a new release itself is then done via a GitHub workflow no matter what, i.e. is triggered by pushing the tag. git push origin $version could (and should) be a part of deploy.sh.

Sure, should we just keep "latest" and "previous version" ? How many versions do you think we should keep ?

I'd say the latest version (i.e. the upcoming version based on master, i.e. 0.10.0) and the previous version (i.e. the current stable version, i.e. 0.9.0) at least, but in the end nothing really prevents us from creating a directory for each version and to never actually delete the deployment of old versions (i.e. keep all versions). We could also add a master directory that is updated on every push.

We just have to decide whether we want to add old versions (like 0.8.0, 0.7.2, 0.7.1, …) to begin with. I'm a new Glowing Bear user, so I don't really know how the build process looked before. I can check whether I'm able to build these old versions and add them, otherwise we just leave them. It's a one-time effort no matter what.

I will try to get back to you shortly.

Thanks @cormier! 👍

[lorenzhs]

Sure, I'd be happy to review release automation and a move from (the long broken) travis to GHA, but I can't make any promises about the promptness of reviews.

The old versions didn't have a build process (apart from optional js/css minification), so very easy to deploy - the minified versions are still in the github-pages branch anyway so we wouldn't even have to rerun those.

I mentioned it on IRC earlier but I guess no harm in posting here too:

The cloudflare pages thing is the replacement for hosting all pull requests on latest.glowing-bear.org and I just recently fixed it. It's kinda nice tbh. https://glowing-bear.pages.dev/ is basically the same thing as https://latest.glowing-bear.org/

[cormier]

@lorenzhs, @torhve, or @cormier can you please give me a sign whether you're willing to review, merge, and especially use such a PR before putting effort into this and formalizing a specific proposal?

I would be happy to help on an effort to simplify the release process.

Would it be possible to do without the Makefile and just trigger the release when a tag is pushed ?

Yes. We don't really need a Makefile, I personally just like to use Makefiles because they are universally understood, but I can surely just also create a deploy.sh script (possibly called via npm run deploy) taking the necessary steps. The only important thing here is that we check whether a commit is deployable (like running the test suite, checking whether the version strings were updated, checking whether npm run build doesn't fail, etc.) before pushing the tag, because a tag that has been pushed is a release already (even if deployment fails later; thus we must run these checks first). The deployment of a new release itself is then done via a GitHub workflow no matter what, i.e. is triggered by pushing the tag. git push origin $version could (and should) be a part of deploy.sh.

My understanding of this paragraph is that you consider a process with two different stages. First one is testing (running the test suite, checking whether npm run build doesn't fail), second one is deploying (e.g. pushing the code on the server) ... And we need to make sure that all the steps on the "testing" stage succeed before we proceed to the "deploy" stage. is that correct ?

Now I know I mentionned tagging, but I believe there is a fundamental problem with that. It requires a maintainer stepping up and tagging a version when it is considered stable. I believe that this requirement on having a maintainer judging when a stable version is ready will causes delays in releasing -- and bring us back to the situation we are in right now. What would you all think on automatically releasing whatever is merged on master (if all the steps in the "testing" stage succeed of course)? It seems to me that this is they way folks are using latest.glowing-bear.org. We could also provide a link to an older version. This can be another discussion, but maybe we could simplify the versioning by switching to CalVer.

We just have to decide whether we want to add old versions (like 0.8.0, 0.7.2, 0.7.1, …) to begin with. I'm a new Glowing Bear user, so I don't really know how the build process looked before. I can check whether I'm able to build these old versions and add them, otherwise we just leave them. It's a one-time effort no matter what.

I believe that we should start with the new versions and include the older ones if there is a demand for it.

Thanks @PhrozenByte !