Re: Versioning

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: [email protected]
> For additional commands, e-mail: [email protected]
>