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