FYI, for all the components I've been working on, I have used the x.y.z format.
Gary On Thu, Dec 15, 2022, 11:36 Mark Thomas <ma...@apache.org> wrote: > 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 > >
