Hi.
We should think in term of audience. Yes, git logs are public,
everything we do in this project is, but to what audience compared to
final releases? And 99% of the users are end-users only interested in
releases. The remaining is our internal kitchen business, which is
certainly not under the same quality pressure than releases.
On this regard, not having sequential release versions looks like a flaw
to me, versions are semantically useful to end-users, I don't consider
it a purely cosmetic issue, whereas having a doublon in the git logs
does, and only for advanced users, and sincerely, who cares?
Keeping manual steps minimum is a technical issue which should be solved
once we know what we want - managing release candidates should be
properly done in the maven-release-plugin, it is not, the manual steps
are just here to circumvent this problem. We could certainly do better
(but frankly, it's not that complex, it's copy-pasting), and feel free
to amend the process.
I understand that you went on without taking this versioning constraint
into consideration, no harm in that. But since we always had sequential
versioning in the history of the project, would it be so hard to
continue to enforce it?
Claude
On 17/04/2024 09:12, Michael Osipov wrote:
Am 2024-04-10 um 22:01 schrieb Claude Brisson:
Hi team.
Can we clarify a little bit the versioning for the future releases?
My point of view is quite simple: did the engine 4.2 get released?
No. So it should be the next version. If it's not what is intended, I
need a detailed explanation, because I really don't understand
Michael response:
> because that version should not appear more than once on the log:
https://github.com/apache/velocity-engine/commits/master/.
What do you mean exactly by the fact that a "version" does "appear"
on the "log"? None of those terms are clear to me in this context...
Claude,
the Git log contains the messages from the Maven Release Plugin with
that tag name chosen during release time. E.g.,
"[maven-release-plugin] prepare release 2.4.1" from [1].
Yet another point I'd like to raise is that the should keep manual
steps to a minimum. Avoid gaps in the sequence just creates even more
friction in the release process. Looking at [2], way too complex.
At the end the only viable releases are the source tarball and what
people will download from Maven Central.
Michael
[1]
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#scmReleaseCommitComment
[2] https://velocity.apache.org/release-process.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
