Replace News with GitHub Releases about javalin.github.io HOT 11 CLOSED

I don't think a lot of people read release notes unprompted (the link used to be in the top bar, and less than 1% of users clicked on it. The purpose of the news pages is more to act as an entry point to the website. This box is arguably more important than the post itself.

from javalin.github.io.

It still sounds like a valid point to stop using this in a way it is atm. I'd just move to GitHub releases, it'd be more consistent with how projects are managed on this platform in general + that's how our plugins are released, so it'd be even more consistent between projects in the org. The news may stay hidden as it is now, you'd just leave a link to GitHub releases below this box.

from javalin.github.io.

I don't mind linking to release from a news post, but we probably need to rework our commit messages to get the most out of this?

from javalin.github.io.

Umm it depends, for quite a long time I was writing release notes manually, lately they've added a basic generator, but I think it's up to you how you want to present that. I don't really mind either way, my point here is to just keep it there.

Speaking of the migration, I think it'd be nice to move older releases there as well - we could move all of them or just e.g. all from 3.x/4.x. News are in markdown:

• https://raw.githubusercontent.com/javalin/javalin.github.io/master/_posts/news/pre-6.0/2023-03-04-javalin-5.4.0-released.md

So we could just basically copy-paste this content there.

from javalin.github.io.

I agree with @dzikoysk, I like having releases here.

Since you're already creating tags for each release, it's trivial to automatically generate a release using GitHub actions with the commits.

I use ncipollo/release-action for example.

from javalin.github.io.

But should we then also switch to https://www.conventionalcommits.org/en/v1.0.0/ (or something similar) to get the most out of this setup?

from javalin.github.io.

But should we then also switch to https://www.conventionalcommits.org/en/v1.0.0/ (or something similar) to get the most out of this setup?

Late reply but seems like a good idea. Although you'll be the one doing the commits since you squash when merging.

from javalin.github.io.

I used several approaches, and I personally don't like the convention proposed in this link. The best format that works for me is probably:

Pull request title: GH-{IssueId} Description
Commit message (squash): GH-{PullRequestId} {Description} (Resolves/Fixes {RelatedIssuesIds}

It informs you not only about the type of change, but what's even more important for me, it provides realtively easy way to find associated discussion about requested change (issue) & conversation+decisions made during the impl phase (pull request).

from javalin.github.io.

I used several approaches, and I personally don't like the convention proposed in this link. The best format that works for me is probably:

Pull request title: GH-{IssueId} Description
Commit message (squash): GH-{PullRequestId} {Description} (Resolves/Fixes {RelatedIssuesIds}

It informs you not only about the type of change, but what's even more important for me, it provides realtively easy way to find associated discussion about requested change (issue) & conversation+decisions made during the impl phase (pull request).

I do agree traceability on commits/PRs is important, but its nice to know what the change does right away even if it's not related to an issue/PR.

from javalin.github.io.

We can automate using this two actions:

https://github.com/marketplace/actions/release-drafter
https://github.com/marketplace/actions/gh-release

Also, when a released is published users that choose to are notified.

from javalin.github.io.

This has largely been done now.

from javalin.github.io.