Closed gastaldi closed 1 hour ago
There are two possible (orthogonal) solutions that @gastaldi and I came up with:
latest
version and the version of the actual release performed right now. If actual > current
, then set it as latest.While we are at it, we could also try to set a draft
version automatically or via configuration.
Should we try to see if JReleaser solved the issue already for us?
Should we try to see if JReleaser solved the issue already for us?
That's also another option. Right now we're using JReleaser only to deploy to Central but maybe that could work
@turing85 suggested adding latest
and pre-release
flags in .github/project.yml
and use them in the gh release
call
Should we try to see if JReleaser solved the issue already for us?
That's also another option. Right now we're using JReleaser only to deploy to Central but maybe that could work
However, I'm afraid that using JReleaser for that may require more testing as the configuration to achieve that may not be that trivial
However, I'm afraid that using JReleaser for that may require more testing as the configuration to achieve that may not be that trivial
Well, I mentioned it because it seems trivial. Not sure how smart it is though.
Hi! @gastaldi and I just found something. The new release process auto-generates release notes. This new process does not honor SemVer. So for example, if we release a version
3.6.0
and a version3.5.1
afterwards (which we just did inquarkus-artemis
), the later version (i.e.3.5.1
) will be set aslatest
.Originally posted by @turing85 in https://github.com/quarkiverse/quarkiverse/discussions/284#discussioncomment-11044571