On 14/12/2022 12:12, Gilles Sadowski wrote:
Hi.

Le mer. 14 déc. 2022 à 12:25, Gary Gregory <garydgreg...@gmail.com> a écrit :

I would create a branch called "1.x" instead and bump the version in the
POM to 1.5.0.

FYI, I've been using the x.y.z version format in most of not all components
I work on, I find that it sets expectations better, for me anyway.

IIRC, the convention is to use "x.y" if "z" is "0".

I have a very strong perference for always including the z component even if it is zero. That said, for consistency I intend to follow whatever pattern (I haven't looked yet) file upload used for the previous 1.x releases.

If a third number refers to "patch" or "bug fix", and there hasn't
been any, it is rather more confusing.

I disagree. I see greater confusion between 1.y referring to the specific 1.y(.0) release or the series of 1.y releases. If the .z component is always present, there is no opporutnity for confusion.

IMO, this is the kind of thing that should be consistent across all
releases within a project; so departing from the common (and
Commons') practice should not occur without a vote.

If the process wasn't established with a VOTE there there is no need for a VOTE to deviate from it.

It seems reasonable that there should be a consistent versioning format but it isn't clear if we'd be able to reach consensus on what that should be.

Perhaps the same remark about naming (git) "tags".

Ditto.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to